[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <471F8AC5.9080300@simon.arlott.org.uk>
Date:	Wed, 24 Oct 2007 19:11:17 +0100
From:	Simon Arlott <simon@...e.lp0.eu>
To:	Adrian Bunk <bunk@...nel.org>
CC:	Chris Wright <chrisw@...s-sol.org>, 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>,
	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 24/10/07 13:55, Adrian Bunk wrote:
> On Wed, Oct 24, 2007 at 12:50:29PM +0100, Simon Arlott wrote:
>> I currently have an LSM that only handles permissions for socket_bind
>> and socket_listen, I load it and then "capability" as secondary on
>> boot - but now I can't because the LSM framework is now just the LS
>> framework.
>> 
>> Why can't this "static LSM" change be a Kconfig option?
>> (I don't want to have to maintain my own reverted copy of security/,
>> or compile this into the kernel because then I can't ever modify and
>> reload it without rebooting.)
> 
> Let's start with the more important questions:
> 
> Did you submit your LSM for inclusion into the kernel?
No, because the interface for configuring it would be rejected... I have 
a /proc file which I write a binary configuration file to. This works 
fine for me but it would take a lot of work to write a proper interface 
- which I'm still not sure how to do*.
That doesn't solve the problem that it's no longer possible to reload LSM 
modules to make changes at runtime. Why should I have to reboot to change 
something from now on when it works ok? The reasoning seems to be based 
around a dislike of some out of tree modules. (Although it doesn't look 
like there's appropriate locking around the register/unregister process.)
* (I've got a list of access rules which are scanned in order until one of 
them matches, and an array of one bit for every port for per-port default 
allow/deny - although the latter could be removed.
http://svn.lp0.eu/simon/portac/trunk/)
-- 
Simon Arlott
-
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