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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
