Re: [PATCH] disallow modular capabilities

[Andi Kleen <ak@muc.de>]

On Sun, Jan 02, 2005 at 05:36:50PM -0500, David Meybohm wrote:
> On Sun, Jan 02, 2005 at 09:47:41PM +0100, Andi Kleen wrote:
> > Christoph Hellwig <hch@lst.de> writes:
> > >
> > > At least Debian currently inserts the capabilities module on boot.
> > 
> > That is fine as long as they control all code executed before
> > that module loading.  And if they do not it is their own fault
> > and they have to fix that in user space or compile the capability in.
> > Unix policy is to not stop root from doing stupid things because
> > that would also stop him from doing clever things.
> 
> But if the module system creates security holes in the security system,
> shouldn't that be avoided?  Isn't this is a fundamental problem because

A kernel module is by definition a security hole. It can do everything,
including setting the uids of all processes to 0.

> the new security module that is being loaded has no idea what state all
> processes are in when the module gets loaded?

This can still be fine if you don't care about the security of 
everything that runs before (e.g. because it is controlled early
startup code). If you care about their security don't do it when
it hurts. 

> What do you think about only allowing init to load LSM modules i.e.
> check in {mod,}register_security that current->pid == 1.  Then init can
> load the policy from some file in /etc changeable by the administrator
> before starting any other processes.  Then you don't have to recompile
> the kernel to change policies, but you still need to reboot and can't
> get into funky states.

I think it's a bad idea. Such policy should be left to user space.

-Andi