Re: [RFC][PATCH 0/11] security: AppArmor - Overview

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


* Dave Neuer <[email protected]> [2006-04-21 23:41]:
> On 4/21/06, Stephen Smalley <[email protected]> wrote:
> >
> > IIUC, AppArmor does impose such constraints, but only from the
> > perspective of an individual program's profile.  Upon link(2), they
> > check that the program had link permission to the old link name and that
> > both the old link name and new link name have consistent permissions in
> > the profile, and they prohibit or limit by capability the ability to
> > manipulate the namespace by confined programs.  But this doesn't mean
> > that another program running under a different profile can't create such
> > a link (if allowed to do so by its profile, of course), or that an
> > unconfined process cannot do so.  There is no real "system policy" or
> > system-wide security properties with AppArmor; you can only look at it
> > in terms of individual programs (which themselves are identified by path
> > too).
> >
> > > However, I'll say up front that such an argument would only suffice to
> > > move it from "broken" to "very brittle in face of changes" (for instance,
> > > would such a hardlink restriction cause collateral damage that an attacker
> > > could exploit?  How badly does it fail in the face of a misdesigned policy?)
> >
> > Indeed.  I think Thomas Bleher made a good assessment of it in:
> >
> But what about Dr. Cowan's response at:

I didn't have time to answer his mail then, but I will try to do so now.

Mr. Cowan asserts that today Linux is used mainly as a single-user
machine or a dedicated network servers and that AppArmor is designed to
secure these.
For me, this is not enough, because I also need to secure multi-user
computers and I don't want to learn a new security mechanism for these
machines. (I worked several years as a system administrator for a
university where this was my main job).

But the more important point is that, IMO, AppArmor also fails to secure
e.g. dedicated network servers. Consider for example an Apache server
where users are allowed to install CGIs. How do you prevent an attacker
from subverting a buggy CGI and using the host to send spam? 
(Hint: It's really easy using standard SELinux policy).

> In particular, if you don't trust your users, why do you give them the
> ability to create links?

Well, let's have a look at how Linux is used at e.g. university (that's
where I have the most experience). Lot's of untrusted students, doing
lots of weird things. They need to be allowed to run all sorts of
software, experiment with Linux, share files locally and so on. It's not
easy to confine such users.

On those machines, you don't care very much about individual users (if a
user is stupid enough to get his account hacked you just wipe his
homedir and restore from backup), but you do care about system integrity
and secrecy of things like /etc/shadow.
It is possible to confine such a system using SELinux (I've done it). Is
it possible using AppArmor? As far as I understood it is not. For me,
that's a severe limit in functionality.


Attachment: signature.asc
Description: Digital signature

[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]
  Powered by Linux