Messages in this thread | | | Date | Wed, 19 Apr 2006 14:10:39 -0700 | From | Crispin Cowan <> | Subject | Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks |
| |
Yuichi Nakamura wrote: > "Serge E. Hallyn" wrote: > >> Have you ever tried, at 4pm some afternoon, sitting in a room with >> somepaper and implementing the AA user interface on top of selinux? >> > We've implemented AppArmor like configuration on top of SELinux. > SELinux Policy Editor(http://seedit.sourceforge.net/) does this. > This is a fascinating piece of work. A compiler to compile (approximately) AppArmor policies into SELinux policies.
> Above is converted into SELinux Policy language. > Types, allow rules,domain transision rules are generated. > Does it label the file system as well? If not, then the path names you can specify with different access rights would be very limited. If so, then any change to the policy requires a relabellings.
> It works, and can also restrict IPC and privilege other than POSIX > capability(because it is based on SELinux). > We have plans to enhance AppArmor to mediate IPC and network access. Some of these plans are constrained by the limits of LSM, and once AppArmor is in-tree, we hope to propose some LSM enhancements to make that work better.
> However, path-name based configuration can not be achieved on SELinux in > following cases. > 1) Files on file system that does not support xattr(such as sysfs) > SELinux policy editor handles all files as same on such file systems. > More than just sysfs. All network attached storage (NFS mounted file systems) cannot support xattr. One could imagine supporting xattr for Linux-based NFS servers, but that just won't work for non-linux storage servers.
As a consequence, SELinux policies can only grant all-or-nothing access to the entire NFS-mounted file system. This is a big deal for larger data centers, where everything is in network attached storage, and Linux is fighting its way in. Pathname based access control gives you much finer granularity of access control on which NFS mounted files an application can access.
Note that the insecurity of NFS due to lack of authentication is irrelevant here. Access controls on an NFS server would be insecure because the clients are spoofable. However, what AppArmor does is constrain an application on the NFS client with respect to which *imported* files it can access.
> 2) Files that are dynamically created/deleted(inode number is not fixed). > Example is files on /tmp and /etc/mtab. SELinux Policy Editor is > using file type transition to configure access control for them. > This also is an important distinction. AppArmor can specify policy for files that don't exist yet. SELinux can specify policy for files that don't exist yet, but only in so far as you can write TE rules for labels that do exist, and will be applied to the files when they are created.
Suppose we want to write a profile for fingerd. In AppArmor, the rule would be "/home/*/.plan r" to grant read access to everyone's .plan file. Some people don't have a .plan file, but they do create them ad hoc as time goes on. What does seedit do in that case?
A more problematic case in classic SELinux is personal public_html directories http://fedora.redhat.com/docs/selinux-apache-fc3/sn-simple-setup.html
The goal is to allow Apache to access everyone's public_html directory, but not the rest of their homedir files. The problem is that each file can only have a *single* label on it, and so what label to put on public_html directories and their contents?
* If you choose user_homedir_t then either o Apache cannot access public_html directories at all, or o Apache gets access to all user homedir contents, including potentially nasty secrets. Not so nice to have your personal secrets leaked out through the web server. * If you choose httpd_sys_content_t then either o Users cannot access their own public_html directories, which is useless, or o Users can write to the system web pages, which means any user can change the system home page.
None of the above alternatives are pretty. To solve this problem in a labeled system, you would have to have some way of attaching more than one label to a single file. You can fake that by creating a software MUX that encodes multiple labels into a single label, but that creates an explosion in the number of labels. You have to have a new MUX for every system daemon that needs to access homedir contents. There is also the problem that the public_html directory might be removed and re-created by the user, resulting in it automatically inheriting the user_homedir_t label.
This page http://fedora.redhat.com/docs/selinux-faq-fc5/#id2978458 solves the problem by labeling public_html with httpd_user_content_t. This eliminates the need for a MUX by applying the same label to all user public_html directories. But it is unclear which applications can author httpd_user_content_t content -- and i'm not sure if users are allowed to relabel their files.
Or you can use an AppArmor rule of "/home/*/public_html/** r".
Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |