Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

["Simon Arlott" <simon@fire.lp0.eu>]

On Wed, October 24, 2007 23:31, Adrian Bunk wrote:
> On Wed, Oct 24, 2007 at 07:11:17PM +0100, Simon Arlott wrote:
>> 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*.
>>...
>
> Generally, the goal is to get external modules included into the kernel.
>
> You want to be able to have this functionality and you do not want to
> use SELinux for it.

SELinux couldn't do it when I wrote my own module, it may do now but I
haven't checked - that's also far too much extra configuration overhead
to do something relatively simple.

> But instead of working on getting your code into the kernel you are
> requesting that an API making it easier for you to maintain it
> externally comes back.

It's also much harder to maintain it internally too since it can no
longer be compiled as a module. If it were possible to have to make LSM
usable as a module but without secondary support, that would make
development easier - although secondary support is so trivial I doubt
it makes a difference to the possibility of allowing it to be compiled
as a module again.

> There are other points in this thread that might or might not warrant
> making LSM modular again, but even though it might sound harsh breaking
> external modules and thereby making people aware that their code should
> get into the kernel is IMHO a positive point.

You're only going to be forcing me to spend *my* time developing it into
something that could be accepted into the kernel when it works fine for
me already. Then I'd have to convince the LSM maintainer(s) that it
should be merged - this isn't like an external hardware driver where
there's no existing support in the kernel.


>> Simon Arlott
>
> cu
> Adrian


-- 
Simon Arlott