[ubuntu-hardened] Re: AppArmor for Ubuntu

[Thomas Bleher]

* Seth Arnold <seth.arnold at suse.de> [2006-03-02 21:47]:
> On Wed, Mar 01, 2006 at 02:09:09AM +0100, Thomas Bleher wrote:
> > Obvious question: How do you handle hardlinks?
> > How do you prevent a malicious program running as root from reading
> > /etc/shadow if the file is linked to /tmp/innocent and the program is
> > allowed to read files under /tmp?
> 
> It is a matter of perspective. Typical label-based systems assume all
> processes are malicious and thus require much policy to address what
> they are allowed to do, which objects can be relabelled in which ways,
> etc.
> 
> Our perspective is slightly different, and we feel it is one that more
> closely matches the needs of typical Linux users.
> 
> The AppArmor approach says that you will confine every process you do
> not trust. Any unconfined process is one you trust.
> 
> A confined process can make hardlinks when (a) link permission is
> granted to the link name (ln(1) semantics; "newpath" in link(2)
> semantics) (b) the permissions on both the target and link name are
> identical in the profile. (With the exception of the 'l' permission.)
> 
> A confined process thus cannot use a hardlink to gain more privileges
> than what is specified. The only way it could do so is via a second
> process. There are two cases to consider: either the second process is
> unconfined or the second process is also confined.
> 
> In the first case, the cooperating process is unconfined. Because it is
> unconfined, by definition it is allowed to do anything. You trust it.
> (If you didn't, you'd confine it. ;)
> 
> In the second case, the second process is confined. It can create a
> hardlink to a file if both (a) it has identical permissions on both
> source and destination (b) it also has 'link' permission on the
> destination. This attack makes sense if the second process has:
>   /etc/shadow r,
>   /tmp/foo rl,
> and the first profile has:
>   /tmp/foo w,
> 
> Due to an unfortunate coincidence (link permission is required to unlink
> files currently), 'link' access is liberally scattered about. The profiles
> we're going to ship for SUSE Linux 10.1, SLES10, NLD10, currently include
> 107 uses of the link permission.
> 
> So far, this hasn't been a large concern for two reasons: First,
> and most important, coordinated attacks are not in our primary threat
> model; we have been more concerned with confining the effect of a single
> compromised domain.
> 
> Second, a nice mitigating factor, most system administrators create
> enough partitions such that users are unable to create hardlinks to
> 'important' files.

Thank you very much for your explanation.

OK, this certainly is a valid perspective, but I feel it is a very
dangerous one. At least you should educate your users as most won't be
aware of the issues.

Let's consider the following scenario:
You don't completely trust your users. Confining them is not really
practical because they do many different things, eg read many different
files in /etc and all over the system (as a sidenode: do you have
inverted regexps, so that you can say: read everything in /etc, except
/etc/shadow?).
So what do you do? Probably you would confine every daemon and
privileged program so if there is a flaw in one of them your users can't
use it to escalate their privileges. One of these programs is a
ftp server which runs as root and (among other things) gives the
user read and write access to his homedir via ftp.
Assume further that the system just has one big partition[1].
Now the user find's an exploitable hole in the ftp server.
With SELinux the system is still safe (as a whole) because there's no
way the ftp server can read /etc/shadow (or any other critical file it
couldn't read before).
With AppArmor (as you describe it) the system is now compromised because
the user can just link /etc/shadow into his homedir and read it from
there with the help of the compromised daemon (or even write to it and
create a new account with uid 0!).

The more I think about this, the more problematic this seems:
I don't think there's any way to confine a ftp daemon like I described
above, even if you only have trusted users.
Just compromise the ftp daemon, modify one user's .bashrc to link
/etc/shadow to his homedir, and voila, the next time this user logs in
you have the file.
Does AppArmor provide any means to prevent this? I have a hard time
believing that there are holes as big as these in the security design of
AppArmor.
I would appreciate your comments if the situation is as I decribed it
above.

To me, this security model seems very fragile and hard to analyze, but
then, this is why I use SELinux.

Thomas

[1]: Yes, I know that it is better to partition the system, but in my
experience many users don't do this or know about the security benefits;
the security of our MAC system shouldn't depend on this.