On Tue, 2005-07-19 at 13:24 -0700, Casey Schaufler wrote: > 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. The question is whether the kernels of those systems provided: a) only an xattr API to userspace, with the API for getting and setting specific attributes like MAC labels and ACLS done entirely in userspace on top of the kernel xattr API, or b) multiple separate APIs for distinct attributes like ACLs and MAC labels as well as the xattr API. Linux presently does (a). FreeBSD does (b) last I looked. > > 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. I'm not asking how the kernel knows how to label the inode. I'm asking how /bin/ls finds out the MAC label of the inode when there is no real xattr storage, and the only kernel API available is getxattr(2). Ultimately, this has to be answered by the security module, as the security information is stored in the inode security structure managed by the security module and the fs code has no knowledge of that structure. fs code doesn't even handle such mount options in Linux; they are handled by the security module, as such security-specific interpretation depends on the particular security module. > 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. Again, the kernel knows how to label, but exporting it to userspace is the issue, particularly when the fs code is security policy agnostic. > > > 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. Again, the question is not how the kernel determines the label, but how the kernel exports it to userspace. In this case, getxattr(2) just returns -ENODATA, and we don't want to change that, as userspace may legitimately need to know that the inode has no xattr set. But we do want a way for userspace to discover how the security module is internally labeling the inode for access control purposes. > > 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. getxattr(2) calls into the fs code to get the xattr, so it will just return the on-disk xattr value unless the security module prohibits the getxattr operation (which SELinux does in this case where mountpoint labeling is used, returning -EOPNOTSUPP, so that userspace does not mistakenly use the on-disk xattr value). There is no kernel mac_get_file API; the equivalent is just a library function that ultimately calls getxattr(2) in Linux. > 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. There is no xattr storage in the pseudo filesystem case. Just the incore inode security structure, which is entirely managed by the security module, and the fs code cannot interpret it. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Mon Jul 25 2005 - 08:22:26 PDT