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.
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
Christoph Hellwig <[email protected]> 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
On Sun, Jan 02, 2005 at 09:28:00PM +0100, Andi Kleen wrote:
> Christoph Hellwig <[email protected]> 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.
Christoph Hellwig <[email protected]> writes:
> On Sun, Jan 02, 2005 at 09:28:00PM +0100, Andi Kleen wrote:
>> Christoph Hellwig <[email protected]> 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
On Sun, Jan 02, 2005 at 09:47:41PM +0100, Andi Kleen wrote:
> Christoph Hellwig <[email protected]> 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
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 <[email protected]> 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
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
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
* 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.
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
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
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.
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
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
* Christoph Hellwig ([email protected]) 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