--- 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