--- Stephen Smalley <sds@private> wrote: > 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. Security attributes are stored as "root" attributes. The xattr interface does not make them generally available, even to the owner. 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. > 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). 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. > 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. 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. > 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. The set of mount options for Linux file systems is (cough) rich. It would seem that adding some ought not be that challenging. > Again, the kernel knows how to label, but exporting > it to userspace is > the issue, particularly when the fs code is security > policy agnostic. The mac_get_file() mac_set_file() interfaces form the .1e Draft are also agnostic. > 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. Yes. As above, getxattr() is not a good choice. > There is no kernel > mac_get_file API; the equivalent is just a library > function that > ultimately calls getxattr(2) in Linux. This is a bug. It is incorrect behavior that cannot be corrected in userspace. > There is no xattr storage in the pseudo filesystem > case. Create some, or add a pointer to the process attribute or whatever makes sense. > Just the > incore inode security structure, which is entirely > managed by the > security module, and the fs code cannot interpret > it. Perhaps you should revisit some of your design choices so that you can take better advantage of the facilities that are available. 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 : Mon Jul 25 2005 - 09:16:22 PDT