[PATCH] disallow modular capabilities

[PATCH] disallow modular capabilities

[Christoph Hellwig]

There's been a bugtraq report about a root exploit with modular
capabilities LSM support out for more than a week.

This patch fixes it the hard way by disallowing to build the code
modular.  In fact I think allowing modular security policies is a 
really, really bad idea because loading it after boot loses far
too much state.  Would you take a patch killing the exports in
security/ ?


--- 1.10/security/Kconfig	2004-10-20 10:37:08 +02:00
+++ edited/security/Kconfig	2005-01-02 20:50:35 +01:00
@@ -54,7 +54,7 @@
 	  If you are unsure how to answer this question, answer N.
 
 config SECURITY_CAPABILITIES
-	tristate "Default Linux Capabilities"
+	bool "Default Linux Capabilities"
 	depends on SECURITY
 	help
 	  This enables the "default" Linux capabilities functionality.

Re: [PATCH] disallow modular capabilities

[Christoph Hellwig]

On Sun, Jan 02, 2005 at 09:00:32PM +0100, Christoph Hellwig wrote:
> There's been a bugtraq report about a root exploit with modular
> capabilities LSM support out for more than a week.

Umm, forgot the url:
http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2004-12/0390.html

Re: [PATCH] disallow modular capabilities

[Andi Kleen]

Christoph Hellwig <hch@lst.de> writes:

> There's been a bugtraq report about a root exploit with modular
> capabilities LSM support out for more than a week.

It was a root exploit only triggerable by root. Not exactly
what I would call a real problem.

-Andi

Re: [PATCH] disallow modular capabilities

[Christoph Hellwig]

On Sun, Jan 02, 2005 at 09:28:00PM +0100, Andi Kleen wrote:
> Christoph Hellwig <hch@lst.de> writes:
> 
> > There's been a bugtraq report about a root exploit with modular
> > capabilities LSM support out for more than a week.
> 
> It was a root exploit only triggerable by root. Not exactly
> what I would call a real problem.

At least Debian currently inserts the capabilities module on boot.

Re: [PATCH] disallow modular capabilities

[Andi Kleen]

Christoph Hellwig <hch@lst.de> writes:

> On Sun, Jan 02, 2005 at 09:28:00PM +0100, Andi Kleen wrote:
>> Christoph Hellwig <hch@lst.de> writes:
>> 
>> > There's been a bugtraq report about a root exploit with modular
>> > capabilities LSM support out for more than a week.
>> 
>> It was a root exploit only triggerable by root. Not exactly
>> what I would call a real problem.
>
> 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.

-Anddi

Re: [PATCH] disallow modular capabilities

[David Meybohm]

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
the new security module that is being loaded has no idea what state all
processes are in when the module gets loaded?

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.

Dave

Re: [PATCH] disallow modular capabilities

[Andi Kleen]

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

Re: [PATCH] disallow modular capabilities

[David Meybohm]

On Mon, Jan 03, 2005 at 12:30:39AM +0100, Andi Kleen wrote:
> 
> A kernel module is by definition a security hole. It can do everything,
> including setting the uids of all processes to 0.

Yes, but allowing the administrator to easily unintentionally create
security holes in loading a security module defeats the whole purpose of
having modular security.

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

But this also means every security module has to handle the case of
being loaded after this time in the boot process interactively by
administrators.  That's very complex and race-prone.

> > What do you think about only allowing init to load LSM modules i.e.
> > check in {mod,}register_security that current->pid == 1.
> 
> I think it's a bad idea. Such policy should be left to user space.

Well, by excluding some policy you have to put more code in the kernel
in the LSM modules to handle being loaded at any time.  So, I don't
think the dogma of "no policy in the kernel" is a good one to follow
here:  it ignores the problem and creates new ones.

Dave

Re: [PATCH] disallow modular capabilities

[Andi Kleen]

On Sun, Jan 02, 2005 at 07:21:02PM -0500, David Meybohm wrote:
> > > 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. 
> 
> But this also means every security module has to handle the case of
> being loaded after this time in the boot process interactively by
> administrators.  That's very complex and race-prone.

The administrator has to prevent the case or make sure
it doesn't cause any problems.

You just have to be careful to not start any daemons before it,
safest is probably to load it in the initrd.

> 
> > > What do you think about only allowing init to load LSM modules i.e.
> > > check in {mod,}register_security that current->pid == 1.
> > 
> > I think it's a bad idea. Such policy should be left to user space.
> 
> Well, by excluding some policy you have to put more code in the kernel
> in the LSM modules to handle being loaded at any time.  So, I don't

> think the dogma of "no policy in the kernel" is a good one to follow
> here:  it ignores the problem and creates new ones.

The kernel just assumes that root knows what he/she/it is doing.
Zillions of other kernel interfaces make the same assumptions.

-Andi

Re: [PATCH] disallow modular capabilities

[Florian Weimer]

* Andi Kleen:

>> think the dogma of "no policy in the kernel" is a good one to follow
>> here:  it ignores the problem and creates new ones.
>
> The kernel just assumes that root knows what he/she/it is doing.

Is there any documentation that says that you must load security
modules immediately?  If there isn't, this assumption is a bit
far-fetched.

Re: [PATCH] disallow modular capabilities

[Alan Cox]

On Llu, 2005-01-03 at 00:32, Andi Kleen wrote:
> You just have to be careful to not start any daemons before it,
> safest is probably to load it in the initrd.

In which case a documentation patch is needed and maybe some __init code
at boot which checks whether it can safely insert and errors if not

Re: [PATCH] disallow modular capabilities

[Lee Revell]

On Sun, 2005-01-02 at 21:00 +0100, Christoph Hellwig wrote:
> There's been a bugtraq report about a root exploit with modular
> capabilities LSM support out for more than a week.
> 

And I posted this to LKML almost a week ago, and a real fix was posted
in response.

http://lkml.org/lkml/2004/12/28/112

Lee

Re: [PATCH] disallow modular capabilities

[Linus Torvalds]

On Tue, 4 Jan 2005, Lee Revell wrote:
> 
> And I posted this to LKML almost a week ago, and a real fix was posted
> in response.
> 
> http://lkml.org/lkml/2004/12/28/112

Well, I realize that it has been on bugtraq, but does that make it a real 
concern? I'll make the tristate a boolean, but has anybody half-way sane 
ever _done_ what is described by the bugtraq posting? IOW, it looks pretty 
much like a made-up example, also known as a "don't do that then" kind of 
buglet ;)

		Linus

Re: [PATCH] disallow modular capabilities

[Christoph Hellwig]

On Tue, Jan 04, 2005 at 01:05:29PM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 4 Jan 2005, Lee Revell wrote:
> > 
> > And I posted this to LKML almost a week ago, and a real fix was posted
> > in response.
> > 
> > http://lkml.org/lkml/2004/12/28/112
> 
> Well, I realize that it has been on bugtraq, but does that make it a real 
> concern? I'll make the tristate a boolean, but has anybody half-way sane 
> ever _done_ what is described by the bugtraq posting? IOW, it looks pretty 
> much like a made-up example, also known as a "don't do that then" kind of 
> buglet ;)

I don't think this particular one is too serious.  But I think we'll see
more serious issues with other modular security modules.

The security modules aren't really as isolated as all the driver modules
we have as they're deeply interwinded with the process/file/etc state.

Re: [PATCH] disallow modular capabilities

[Lee Revell]

On Tue, 2005-01-04 at 13:05 -0800, Linus Torvalds wrote:
> 
> On Tue, 4 Jan 2005, Lee Revell wrote:
> > 
> > And I posted this to LKML almost a week ago, and a real fix was posted
> > in response.
> > 
> > http://lkml.org/lkml/2004/12/28/112
> 
> Well, I realize that it has been on bugtraq, but does that make it a real 
> concern? I'll make the tristate a boolean, but has anybody half-way sane 
> ever _done_ what is described by the bugtraq posting? IOW, it looks pretty 
> much like a made-up example, also known as a "don't do that then" kind of 
> buglet ;)

Well, a buglet is still a type of bug ;-)

What's wrong with Serge's patch?  I don't see any downside.

http://lkml.org/lkml/2004/12/29/59

Lee

Re: [PATCH] disallow modular capabilities

[Chris Wright]

* Christoph Hellwig (hch@lst.de) wrote:
> On Tue, Jan 04, 2005 at 01:05:29PM -0800, Linus Torvalds wrote:
> > On Tue, 4 Jan 2005, Lee Revell wrote:
> > > And I posted this to LKML almost a week ago, and a real fix was posted
> > > in response.
> > > 
> > > http://lkml.org/lkml/2004/12/28/112
> > 
> > Well, I realize that it has been on bugtraq, but does that make it a real 
> > concern? I'll make the tristate a boolean, but has anybody half-way sane 
> > ever _done_ what is described by the bugtraq posting? IOW, it looks pretty 
> > much like a made-up example, also known as a "don't do that then" kind of 
> > buglet ;)
> 
> I don't think this particular one is too serious.  But I think we'll see
> more serious issues with other modular security modules.

It's only a problem when you care about the state of things that have
run before the module is loaded.  This ranges between no problem and
major problem on a case by case basis.  For example, really makes sense
to have SELinux only compiled in.  For this one, we can just track
capabilities bits in default dummy stub code, it's painless and allows
keeping capabilities modular for those who use it that way.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net