[ubuntu-hardened] Re: AppArmor for Ubuntu

[Crispin Cowan]

Thomas Bleher wrote:
> 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.
>   
Certainly there is a method to securing a machine with AppArmor. The
intent is more to contain applications so that the application cannot be
used as a port of entry. If you do that to all of the applications, then
AppArmor controls all of the ways to penetrate the machine.

AppArmor comes with an analyzer that helps you to secure against a
network threat. It scans your machine for open network ports, finds the
programs listening to those open network ports, and then reports the
AppArmor profiles wrapped around those programs. If you can get your
machine to the point that all open ports lead to AppArmor profiles, then
it is the case that AppArmor policy completely controls what a network
attacker can do.

> 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
Actually it is practical to confine users, depending on what they
propose to do. For instance, you want to have a "syslog analyst" role on
your servers. This user needs root privs to be able to read
/var/log/messages, but you don't trust them completely, somewhat for
being possibly malicious, but more likely just to not "oops" and destroy
things by mucking about.

So you create a special shell called "logbash" which is just a hard link
to bash. Then you create a profile for logbash in monkey-see, monkey-do
fashion of just run the commands and access the files that the log
analyst would need to access, and then us AppArmor's profile generator
to turn it into policy.

Finally, to put "Alice" into the log analyst role, you make their
default login shell be "logbash" and set their UID to 0.

On the other hand, if you want to give your friends logins on your box
and let them do anything they want, except you want to block 'bad'
things, then no, AppArmor is not the right tool. Giving them non-root
accounts is the right tool :)

>  (as a sidenode: do you have
> inverted regexps, so that you can say: read everything in /etc, except
> /etc/shadow?).
>   
Not now, but coming in the next release. More specifically, we are going
to add negative profiles, for a variety of reasons.

> 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.
The AppArmor threat model is to confine the daemons so that *network*
attackers cannot compromise the daemons.

>  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.
>   
In the AppArmor model, you would confine the FTP daemon to only have
access to what it should access. It would have read-only access to
/etc/shadow. It might have have rw access to /home/*/** if users are
permitted to FTP to their homedirs.

However, the other half of your attack where an unconfined user messes
around with link, is simply not permitted on an AppArmor machine. You
either confine users logins in the way I described above (which makes
them fairly restricted login shells) or you are *trusting* them, in
which case if they mess around with links they are abusing trust.

This design reflects what I see as real usage of modern machines:

    * Single-user machines, where the user is owner of the machine, e.g.
      my laptop. Here I use AppArmor to confine Internet clients like
      Gaim and Firefox, to prevent malicious content from compromising
      my machine.
    * Dedicated network servers: Mail server, web server, FTP server,
      etc. Non-trusted users use these machines, but not with
      fully-powered login shells. Rather, they would have accounts on
      the network service provided, e.g. a mailbox. A user with FTP
      access would have read/write permission to FTP stuff in and out,
      but would not have any access to commands to create links.

The classic shell server is relatively uncommon in modern computing.
Here, you need to decide how much you trust the users. If you really
trust them, then don't confine them, but also don't be surprised if they
have the power to hack the machine. If you do trust them, then confine
them. The amount of work necessary to build a profile for the user is
proportionate to the span of things you want the user to be permitted to do.

> To me, this security model seems very fragile and hard to analyze, but
> then, this is why I use SELinux.
>   
It is actually really easy to understand, if you approach it from the
right threat model. Consider only threats from confined processes, and
analyze the entire machine only to the extent of determining which
programs need to be confined.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
	Olympic Games: The Bi-Annual Festival of Corruption