linux-kernel - Re: AppArmor FAQ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1177004790.27654.147.camel@moss-spartans.epoch.ncsc.mil>
Date:	Thu, 19 Apr 2007 13:46:30 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Karl MacMillan <kmacmill@...hat.com>,
	David Safford <safford@...son.ibm.com>,
	James Morris <jmorris@...ei.org>,
	John Johansen <jjohansen@...e.de>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: AppArmor FAQ

On Tue, 2007-04-17 at 20:05 +0200, Andi Kleen wrote:
> Karl MacMillan <kmacmill@...hat.com> writes:
>  
> > No - the real fix is to change the applications or to run under a policy
> > that confines all applications. Most of the problems with resolv.conf,
> > mtab, etc. stem from admin processes (e.g., editors or shell scripts)
> > all running under the same unconfined domain.
> > 
> > In some cases applications need modification as only the application has
> > enough information to determine the correct label. Usually this means
> > preserving labels from input files or separating the output into
> > distinct directories so type transitions or label inheritance will work.
> > 
> > restorecond is just a hack not a requirement or a sign that something is
> > wrong with the model. That is why it is a userspace application and not
> > integrated into the kernel mechanism.
> 
> You nicely show one of the major disadvantages of the label model vs the path 
> model here: it requires modification of a lot of applications. 

It is true that many applications that already deal with mode bits need
to become aware of labels, just as with ACLs, and that this makes it a
bit harder and slower to roll out something that is label-based.  But
the right solution is rarely quick and easy, and a lot of work has
already happened to integrate such support into userland.

To look at it in a slightly different way, the AA emphasis on not
modifying applications could be viewed as a limitation.  Ultimately,
users have security goals that go beyond just what the OS can directly
enforce and at least some applications (notably things like X, D-BUS,
PostgreSQL, etc) need to likewise support strong domain separation and
controlled information flow through their own internal objects and
operations.  SELinux provides APIs and infrastructure for such
applications, and has already done quite a bit of work in that space
(D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have
no interest in going there (and would have to recant its emphasis on no
application mods to do so).  If you actually want to truly confine a
desktop application, you can't limit yourself to the kernel.  And the
label model provides a unifying abstraction for dealing with all of
these various objects, whereas the path/"natural abstraction" model has
no unifying abstraction at all.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/