[<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