Re: [RFC][PATCH] Generic fallback for security xattrs

From: Casey Schaufler (casey@schaufler-ca.com)
Date: Tue Jul 19 2005 - 13:24:04 PDT


--- Stephen Smalley <sds@private> wrote:


> > The xattr mechanism works very well, and has
> > a long history that predates inclusion in Linux.
> 
> Not sure how Trix or Trusted Solaris address the
> same issue.
>  Do they
> only export the xattr API, or do they also have a
> separate API for
> getting/setting MAC labels (not just one that is
> layered on top of the
> xattr API)?

They support interfaces from the POSIX
P1003.1e/2c Draft. They use kernel internal
interfaces that closely resemble LSM as
there are rules about setting MAC labels
that are not generally applicable to xattrs.

> If the former, then how do they allow
> userspace to
> unambiguously get the "effective" MAC label of an
> inode when:
> - the filesystem doesn't support xattrs
> (think
> particularly of pseudo
> filesystems and legacy filesystems),

A mount option (e.g. default-mac=userlow)
or, failing that, a generally inaccessable
label (on Trix "msenhigh/mintlow") for
legacy or very special purpose (e.g. autofs)
filesystems.

For a pseudo filesystem you need to understand
its purpose. /proc is easy, you use the MAC
attribute of the associated process. A ramfs
is trivial as well, you start off with a
"reasonable" value for root and follow your
rules from there.

> or
> - the filesystem supports xattrs but the particular
> inode lacks an
> xattr,

Which is a configuration flaw, and requires
mending. This gets the generally inaccessable
label.

> or
> - the filesystem supports xattrs but the particular
> filesystem is
> untrusted (removable media, remote filesystem, etc)
> and the kernel is
> mapping all inodes in it to a particular security
> label specified at
> mount time.

What's the question here? You just said what
it would return, didn't you? The label that
mac_get_file() will return is that which the
file system gives it, which in this case will
be the "mapped" value, not what's in the xattr.
I would highly recommend against providing this
"feature" as it begs the question about why
you would be ignoring the xattr information
while making the data available, but that's
again just me.

> Note that this patch doesn't address the latter two
> issues, which are
> also a concern.

On Trix every file system provides MAC
information to the higher layers. There
are internal LSM-like mechanisms provided
and the access control implementation does
not care how the file system stores or
obtains the information. The information
always comes from the file system.



Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Yahoo! Mail for Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 



This archive was generated by hypermail 2.1.3 : Tue Jul 19 2005 - 13:25:01 PDT