[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0706251358210.20356@asgard.lang.hm>
Date: Mon, 25 Jun 2007 14:02:22 -0700 (PDT)
From: david@...g.hm
To: Pavel Machek <pavel@...e.cz>
cc: Chris Mason <chris.mason@...cle.com>,
James Morris <jmorris@...ei.org>,
Stephen Smalley <sds@...ho.nsa.gov>,
Lars Marowsky-Bree <lmb@...e.de>,
Crispin Cowan <crispin@...ell.com>, Greg KH <greg@...ah.com>,
Andreas Gruenbacher <agruen@...e.de>, jjohansen@...e.de,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,
pathname matching
On Mon, 25 Jun 2007, Pavel Machek wrote:
> Hi!
>
>> We've been over the "AA is different" discussion in threads about a
>> billion times, and at the last kernel summit. I think Lars and others
>> have done a pretty good job of describing the problems they are trying
>> to solve, can we please move on to discussing technical issues around
>> that?
>
> Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/
> allows any user to make AA ineffective on large part of systems -- in
> internal discussion. (It is not actually a _bug_, but it is certainly
> unexpected).
>
> (Does it surprise you, too? I'm pretty sure it would surprise many users).
no, it doesn't surprise me in the least. AA is controlling access to the
thing called /etc/shadow, if you grant access to it in other ways you
bypass the restrictions.
if you follow the ln /etc/shadow /tmp/ with chmod 777 /tmp/shadow the
system is completely insecure.
this is standard stuff that normal sysadmins expect. it's only people who
have focused on the label approach who would expect it to be any
different.
> James summarized it nicely:
>
> # The design of the AppArmor is based on _appearing simple_, but at the
> # expense of completeness and thus correctness.
>
> If even Lars can be surprised by AAs behaviour, I do not think we can
> say "AA is different". I'm afraid that AA is trap for users. It
> appears simple, and mostly does what it is told, but does not do _what
> user wants_.
I thought it had been made very clear that hard links like this were a
potential way around the restrictions, which is why controlled tasks are
not allowed to do arbatrary hard links.
David Lang
-
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/
Powered by blists - more mailing lists