Re: sys_security() status ?

sds@epoch.ncsc.mil

On Sun, 2003-08-24 at 17:45, Philippe Biondi wrote:
> I've seen that these attributes seem very SE Linux oriented, and are
> hardcoded : (fs/proc/base.c)
> 
> #ifdef CONFIG_SECURITY
> static struct pid_entry attr_stuff[] = {
>   E(PROC_PID_ATTR_CURRENT,      "current",      S_IFREG|S_IRUGO|S_IWUGO),
>   E(PROC_PID_ATTR_PREV, "prev", S_IFREG|S_IRUGO),
>   E(PROC_PID_ATTR_EXEC, "exec", S_IFREG|S_IRUGO|S_IWUGO),
>   E(PROC_PID_ATTR_FSCREATE,     "fscreate",     S_IFREG|S_IRUGO|S_IWUGO),
>   {0,0,NULL,0}
> };
> #endif
> 
> How are we supposed to manage a different kind of communication ?
> (for example if I need different files in /proc/<pid>/attr)

If you truly need additional files in /proc/pid/attr, you can submit a
patch to lkml along with a rationale and argue its merits there.  But
first make sure that you cannot support your API via an existing entry
in /proc/pid/attr and that your entry belongs in /proc/pid/attr.  Don't
abuse /proc/pid/attr for arbitrary interfaces to your security module;
it is only for userspace access to process attributes.  The existing set
of nodes should be sufficient for most security modules.

Making /proc/pid/attr extensible would have been contrary to the
existing /proc/pid code - see the comment in proc_pident_lookup,
formerly proc_base_lookup.  Adding new entries to /proc/pid is an
extension of the kernel interface, and the kernel developers naturally
want to vet such extensions, just like adding new system calls.

> I guess this can't be the answer to my previous question.

No, the xattr API (file extended attributes) is separate and orthogonal
from the /proc/pid/attr API (process attributes).  We didn't create the
xattr API; it already existed.  We simply adjusted the LSM hooks to
better support the use of xattr by security modules and added an xattr
handler for a security namespace that can be used by security modules
for file attributes.  The xattr handler is not SELinux-specific; it lets
you get and set attributes with a "security." prefix, so you can use
"security.FOO" for the FOO module's security attributes.  We use
"security.selinux" for our file attributes.  

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

_______________________________________________
linux-security-module mailing list
linux-security-module@mail.wirex.com
http://mail.wirex.com/mailman/listinfo/linux-security-module