[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071028225044.3471f88b@the-village.bc.nu>
Date: Sun, 28 Oct 2007 22:50:44 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Crispin Cowan <crispin@...spincowan.com>
Cc: Ray Lee <ray-lk@...rabbit.org>, Chris Wright <chrisw@...s-sol.org>,
Casey Schaufler <casey@...aufler-ca.com>,
Adrian Bunk <bunk@...nel.org>,
Simon Arlott <simon@...e.lp0.eu>, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
Jan Engelhardt <jengelh@...putergmbh.de>,
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>,
Giacomo Catenazzi <cate@...ian.org>
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to
static interface)
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of $contrivance is just so much FUD.
That seems to be an appropriate test.
> Exception: it is valid to say that the self-stated goal is too narrow to
> be useful. But IMHO that bar of "too narrow" should be very, very low.
> Defenses against specific modes of attack would be a fine thing to build
> up in the library of LSMs, especially if we got a decent stacking module
> so that they could be composed.
Once you have stacking then it actually at times will make sense to have
security modules that do one very precise thing and do it well.
Alan
-
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