[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0710242342540.17781@fbirervta.pbzchgretzou.qr>
Date: Wed, 24 Oct 2007 23:51:13 +0200 (CEST)
From: Jan Engelhardt <jengelh@...putergmbh.de>
To: "Serge E. Hallyn" <serue@...ibm.com>
cc: "David P. Quigley" <dpquigl@...ho.nsa.gov>,
Simon Arlott <simon@...e.lp0.eu>,
Adrian Bunk <bunk@...nel.org>,
Chris Wright <chrisw@...s-sol.org>,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andreas Gruenbacher <agruen@...e.de>,
Thomas Fricaccia <thomas_fricacci@...oo.com>,
Jeremy Fitzhardinge <jeremy@...p.org>,
James Morris <jmorris@...ei.org>,
Crispin Cowan <crispin@...spincowan.com>,
Giacomo Catenazzi <cate@...ian.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to static
interface)
On Oct 24 2007 16:37, Serge E. Hallyn wrote:
>
>Or, a better example, a privileged program reads some sensitive data -
>as allowed by multiadm, writes it to a file, but apparmor prevented it
>from chowning the file to the right user before writing,
Interesting find, I should pay attention to that :-)
But - note to dquigley - AFAICS, an LSM needs to _explicitly_ call
the next LSM's function. No one (just a minimal grep in
linux-2.6/security/) besides SELinux does that today. So
while you could load AppArmor ontop of MultiAdm, it would never
be invoked. This is what is known as "sufficient" in PAM parlance.
SELinux OTOH is in "required" mode [again PAM-speak].
-
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