--- Stephen Smalley <sds@private> wrote: > On Mon, 2005-07-25 at 09:15 -0700, Casey Schaufler > wrote: > > The POSIX P1003.1e interfaces (please read the > > draft sometime, it will help) mac_get_file() > > and mac_set_file() are implemented as system > > calls because they implement a less restrictive > > policy than is required of xattr root attributes. > > Ok, so they had an orthogonal kernel API like > FreeBSD. We don't have > that in Linux, and the original SELinux API (which > had its own calls for > such purposes independent of the xattr API) was > rejected upstream. We > had to re-factor to using the xattr API when we > reworked SELinux for > mainline inclusion in Linux 2.5/6. Possibly you > were sleeping at the > time... Nah. Sleep is for squares! I feel your pain, having lost one or two of these battles myself. But if building mac_get_file() on top of getxattr() doesn't get you what you're after the fact that getxattr() is available isn't a help. > In SELinux (since the migration to 2.6), > applications call functions in > libselinux (e.g. getfilecon, setfilecon), which > internally call the > xattr API, as that is the only kernel API that > exists presently for > getting or setting any kind of attribute. Which is, as you pointed out above, not going to work right. > I'd agree, except that LSM forces us there, eh? Let us just say that the current LSM provides its own set of challenges to be overcome. I don't think it forces us to use the xattr interfaces where they don't work, although that is the obvious approach. > > The set of mount options for Linux file systems > > is (cough) rich. It would seem that adding some > > ought not be that challenging. > > Adding options can be done (and it was done for > SELinux). But the > interpretation/handling of those options is done by > the security module, > as the fs code doesn't know anything about what they > mean. Ah, but getxattr() doesn't need to know what the attribute is good for, just that it should be returned. On the other hand the other problems with a getxattr based mac_get_file() tend to overwhelm this minor victory. > > > Yes. As above, getxattr() is not a good choice. > > Adding new syscalls wasn't an option. Layering on > the xattr API was > strongly recommended for upstreaming. Except that you now know that it doesn't work and can add the issues presented here to you arsenal. > > This is a bug. It is incorrect behavior that > > cannot be corrected in userspace. > > A generic fallback addresses most of the issues. It > still leaves a > problem for certain cases as I noted. Whether or > not those should be > handled by another interface (e.g. selinuxfs) is > unclear, but adding a > parallel API for MAC labels to Linux doesn't seem > likely to fly > upstream. But adding a special case default thingy will? Maybe I should of slept through the whole thing. Casey Schaufler casey@schaufler-ca.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
This archive was generated by hypermail 2.1.3 : Mon Jul 25 2005 - 20:59:58 PDT