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... > The application calls mac_get_file() > (NEVER getxattr) to get the label of a file. > The only instance in which the attributes > are manipulated directly with setxattr() > equivalents is the program attrinit, which > is used to do the initial filesystem labeling > and cannot count on having the MAC modules > installed. 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. > You may have been bitten by one of the > classic security implementation choice > scenarios. You may find that strictly > seperating the security module from the > file system code is not in your overall > best interests. I'd agree, except that LSM forces us there, eh? > 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. > 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. > 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. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Mon Jul 25 2005 - 11:02:38 PDT