[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <252801.14025.qm@web36605.mail.mud.yahoo.com>
Date: Wed, 24 Oct 2007 14:29:43 -0700 (PDT)
From: Casey Schaufler <casey@...aufler-ca.com>
To: Crispin Cowan <crispin@...spincowan.com>
Cc: 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>,
Giacomo Catenazzi <cate@...ian.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)
I have written Smack.
I need an LSM infrastructure.
I would prefer the old dynamic version.
I no trouble with the static version.
I think that a dynamic version is more useful, but I didn't want
what I'm doing to have it as a dependency, so I made sure that
it isn't. The debate about the inclusion of Smack can remain
blissfully separate from the dynamic/static LSM debate. This is
by design.
I have had a couple people suggest changes to Smack that would be
very elegently handled as stacked modules. These include "owned"
ports and additional uid restrictions. Since Smack is a MAC module
these other security features are not really appropriate to include
(if you want the Security Monolith there is SELinux) in it, but
certainly make sense to combine with it.
A stacker that does not require module participation could be quite
interesting. In the old day I felt that a security solution had to
include all aspects of control, but today I see the value provided
by independent mechanisms such as IPtables.
Casey Schaufler
casey@...aufler-ca.com
-
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