disallow modular capabilities
PATCH 1/1 disallow modular capabilities
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/ ?
security/Kconfig +1 -1
@@ -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.
Quoted 2 lines · Christoph Hellwig
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
Quoted 2 lines · Christoph Hellwig
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
Quoted 7 lines · Andi Kleen
Quoted 2 lines · Christoph Hellwig
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.
Quoted 10 lines · Christoph Hellwig
Quoted 7 lines · Andi Kleen
Quoted 2 lines · Christoph Hellwig
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
Quoted 9 lines · Andi Kleen
Quoted 2 lines · Christoph Hellwig
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
Quoted 5 lines · David Meybohm
Quoted 4 lines · Andi Kleen
Quoted 2 lines · Christoph Hellwig
At least Debian currently inserts the capabilities module on boot.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 6 lines
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
Quoted 3 lines · Andi Kleen
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 2 lines
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
Quoted 11 lines · David Meybohm
Quoted 7 lines
Quoted 2 lines
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.
Quoted 11 lines
Quoted 5 lines
Quoted 3 lines
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:
Quoted 4 lines
Quoted 2 lines
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.
Quoted 2 lines · Andi Kleen
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
Quoted 3 lines · Christoph Hellwig
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
Quoted 5 lines · Lee Revell
And I posted this to LKML almost a week ago, and a real fix was posted in response.
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
Quoted 7 lines · Linus Torvalds
Quoted 4 lines · Lee Revell
And I posted this to LKML almost a week ago, and a real fix was posted in response.
Quoted 7 lines
Quoted 1 line
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.
Quoted 7 lines · * Christoph Hellwig ([email protected]) wrote:
Quoted 6 lines · Linus Torvalds
Quoted 4 lines · Lee Revell
And I posted this to LKML almost a week ago, and a real fix was posted in response.
Quoted 8 lines
Quoted 5 lines
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
Signature · 1 line
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Quoted 6 lines · Linus Torvalds
Quoted 4 lines · Lee Revell
And I posted this to LKML almost a week ago, and a real fix was posted in response.
Quoted 7 lines
Quoted 1 line
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