Andreas Gruenbacher wrote: > Could you please try to priefly summarize the intended use of these > security labels? Is this for MAC? Also it would be interesting to know > what the required privileges would be to access the labels. There are > probably some accesses that are allowed in the user's security context, > and some others that are performed on behalf of a user process, but within > the kernel's security context. > > There may be some overlap with trusted extended attributes (see > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/man/man5/attr.5 for a > manual page that contains a minimal description). SELinux implements a flexible MAC architecture that can support many different kinds of MAC security models and includes Type Enforcement, Role-Based Access Control, and optionally Multi-Level Security in the example security server (policy engine). It is not based on POSIX.1e MAC, and POSIX.1e MAC doesn't work so well for non-traditional MAC models like Type Enforcement and Role-Based Access Control. We define a set of permissions that control the ability of a user process to get and set the security label of a file, and the kernel module internally performs get and set operations as appropriate when files are looked up and when new files are created. We originally implemented our own persistent label mapping using some meta-files, but have reworked the SELinux implementation to use xattr if they are available, as you can see in the patch on the NSA site. However, SELinux is merely one of the possible security modules that might be implemented via LSM, so we didn't want to limit this to just SELinux. It seems preferable to reserve a single index and attribute name that can be used by any security module, and use the first few bytes of the attribute value to indicate the particular security module. Most security modules seems to be implementing some form of non-discretionary access control, but the LSM framework isn't specifically limited to that. The xattr_security.c code is actually derived from xattr_trusted.c, but I thought that we should have a separate index and name for an attribute that will be used by MAC schemes like SELinux. Also, the xattr_security.c code differs from xattr_trusted.c in the following important respects: 1) We use a fixed attribute name (system.security) that is not extensible. Every security module would use that name for its attributes (LSM only allows one security module at a time, and any stacking has to be handled by the "principal" security module), and would sanity check the value by checking the first few bytes against some module identifier. Using the "system" prefix seemed appropriate given that this attribute is used internally by the security module and not just by userspace. 2) Permission checking is handled via the security_inode_setxattr hook in fs/xattr.c:setxattr, and updating of the inode's security field to reflect changes to the attribute is handled by a new security_inode_post_setxattr hook added by the patch. The inode semaphore ensures atomicity for the check and update (note that the down is moved by the patch). There is no permission check embedded in the handler itself, since it will vary depending on the security module and depending on whether the call is made from userspace or from the security module itself. -- Stephen Smalley <sdsat_private> National Security Agency _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Apr 10 2003 - 05:07:34 PDT