On Mon, 25 Jun 2007, Hawk Xu wrote:

> James Morris wrote:
> 
> > Convert LSM into a static interface, as the ability to unload a security
> > module is not required by in-tree users
> 
> I'm so confused.
> 
> How do you define in-tree users?

In-tree code is merged into Linus' tree, having passed the community peer 
review and testing processes.

> Currently, who are in-tree users of LSM?

SELinux, and capabilities.

> How many are they?
> Are their needs most important? If yes, why?

Generally, the needs of out of tree code are not considered at all.  An 
exception might be if something is advanced in the merge process.

> How did you get the idea that "in-tree" users do not need to unload security
> modules?

It is not useful or even safe for in-tree users, and the fact that you can 
unload a security module at all means that you need to consider that as 
part of your security system and add even more code & policy to cope with 
it.  So, this unused infrastructure which is not needed and not safe, is 
to be removed.  This will also help reduce abuse of the LSM API.

> If LSM interface is static(people cannot load/unload modules dynamically,
> people cannot use their custom modules with the framework since
> *register_security things are commented out, then why do we need it?

By custom modules, if you mean out of tree modules, their needs are not 
considered.  For that to change, they need to be merged upstream.

The static LSM API will allow you to select which module(s) you want to 
activate.  They can be runtime selected to some extent via kernel 
parameters.

> Why not just merge the in-tree modules into the kernel code (for less 
> performance overhead)?

While LSM exists, it would not make sense to have both LSM hooks and 
SELinux hooks duplicated throughout the code.

> What is LSM framework meant for? For capability? For SELinux? Or for linux
> users all over the world to develop and deploy their custom modules?  What on
> earth is LSM framework meant for?

To allow different security models to be selected.

> 
> People need a camera to make their own home videos, but they don't need to
> integrate their home videos into the design of the camera because other people
> don't need it.  People need to run their custom security modules on the LSM
> framework(without modifying kernel code), but it is not necessary for them to
> make their modules in-tree because the modules are highly customized and only
> suits for special needs.

I suggest reading up on the various talks and papers on the subject of why 
you should try and get your code into the mainline kernel.

See http://www.kroah.com/log/linux/ols_2006_keynote.html

for example.

>  There are few in-tree security modules because it is
> very hard to unify people's security needs, and this does not give any
> justification for removing LSM framework or making it static.
> 
> I don't see any _need_ to make capability a bool option.

Capability already was selectable via a bool.  The need is there so that 
if compiled in statically, you can disable it at runtime.

>  I don't see any
> _justification_ to make the interface static.

The justification has been stated several times now.


-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to