Unprivileged: Disable raising of privileges
in [Kernel]
|
Prev: BFS v0.313 CPU scheduler for 2.6.32
Next: ACPI warning from alloc_pages_nodemask on boot (2.6.33 regression)
From: Alan Cox on 1 Jan 2010 09:50 On Thu, 31 Dec 2009 17:55:27 +0000 (UTC) daw(a)cs.berkeley.edu (David Wagner) wrote: > Alan Cox wrote: > >Removing specific features from a specific piece of code > >generally isn't a security feature - > > You lost me there. The ability of a specific piece of code to voluntarily > relinquish privileges can be a big benefit to security. Can be - but its historically been an endless source of bugs and flaws because the code being run after you take the rights away is being run in an environment it didn't expect and wasn't tested in. From inanities like setting the file size limit to 0 and running passwd blanking the password file (SGI Irix) to closing file handle 0 or setting cpu quotas to make a forked daemon process die unexpectedly the list is endless. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 1 Jan 2010 10:00 > > - unprivileged process took action to prevent gaining a capability. > > - exec'd suid sendmail. > > - sendmail took action as root because it could not become someone else. > > Which is a classic bug and replicated historically in cpu time, quota and > other similar "remove rights and then .." attacks. Yes, so from now on, when we add new "cpu cache misses quota", we should require prctl(I_SHOULD_NOT_BE_ABLE_TO_LAUNCH_SETUID) for unpriviledged users, first. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 1 Jan 2010 11:30 Alan Cox <alan(a)lxorguk.ukuu.org.uk> writes: >> - unprivileged process took action to prevent gaining a capability. >> - exec'd suid sendmail. >> - sendmail took action as root because it could not become someone else. > > Which is a classic bug and replicated historically in cpu time, quota and > other similar "remove rights and then .." attacks. Exactly. The problem that most limits the evolution of the unix userspace API for ordinary processes. I want a per process disable so I can use advanced features of the API without being root (or a subset of root). >> I would like to trivially stop that entire class of exploit by making >> execing a suid ( or equivalent ) executable impossible. > > Fine the LSM modules can already build such policies or you can add a new > LSM for it - it doesn't need whacky one off extensions to prctl. No it needs a proper system call. no_suid_for_me_and_my_children(). Spelled nosuid to keep from breaking peoples fingers. > Of course you could also have an LSM which undoes restrictions on suid > apps instead. Thats an equally valid model, just don't load both at once > and don't assume you have the one true model. Alan what are you talking about? LSMs are not allowed to remove restrictions. You are quite right that my initial patch is a bit hacky, I am doing my development in the open, proving that the concept can be sanely implemented with very little code, and getting feedback from people who know the area of code better than I do. I know development in the open and not having everything perfect and committed to before you submit a patch is a strange concept on linux-kernel, but I am trying it out. My target audience here are application developers. Not professional system administrators, not distribution maintainers, and certainly not professional security trolls. I am about removing an impediment from the unix API for those applications that don't need it so they can use features that would otherwise be reserved to root and only root, because those features can be used to addle suid applications. I am sick and fed up with the conversations that go: - I want to do X. - X has been implemented. - Sorry I can't use X as implemented because you have to be root to use X. In this case X was the network namespace, which for non-root users happens to act just like the proposed disable_network. Putting something in an LSM versus anywhere else in the kernel still pollutes the pool and we still have to maintain it forever. So my preference is for something small, trivial, that people can easily audit. I am not satisfied with my patch to disable suid yet, but it does look simple and in the right ballpark. It certainly needs better integration with securebits and the like. So Alan would you please give some constructive criticism about: - Why this is a bad idea. - How to implement this so it is available to application developers in general. As I see and I may be wrong the LSM and the security modules that exist today are useless unless you control the entire machine the kernel runs on. Which applications short of Oracle do not. Personally I think I am on the sent of a good general feature that makes sense, is useful in a lot of situations, is useful to a lot of different people, and is useful in a lot of different ways. Anything we merge into the mainstream kernel we have to maintain forever, LSM or core feature. I think this is a good backwards compatible feature that removes impediments to forward compatibility. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew G. Morgan on 1 Jan 2010 16:20 2009/12/31 Eric W. Biederman <ebiederm(a)xmission.com>: > "Andrew G. Morgan" <morgan(a)kernel.org> writes: > >> Since there is already independent support for disabling file >> capabilities (the privilege escalation part), I see these two >> mechanisms as separable. > > I guess there is something that resembles support for disabling > privilege escalation. �The problem is that it requires privilege to > use it. Just to be clear, this does not prevent luser1 -> luser2 transitions (even though it does strip root of its privilege), but here is a concrete worked example of what support is in the current kernel. That is, here is a program that cripples privilege in a process tree. Other than setting it up one time, you don't need to become root (or visit a *uid=0) to execute it, and because capabilities are not naively inherited nothing about the privilege of the limiter executable can leak through the execve(). Setup (see below for source code, and http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf for an explanation of how it all works): luser> cc -o limiter limiter.c -lcap luser> sudo /usr/sbin/setcap cap_setpcap=p ./limiter Use: luser> ./limiter /bin/bash [feeling powerless] luser> ...try something privileged... or look at /proc/self/status etc. luser> exit luser> back in parent shell //---- cut here 8< ----- [this is limiter.c] /* Quick demo of blocking privilege */ #include <stdio.h> #include <sys/capability.h> #include <sys/prctl.h> #include <stdlib.h> int main(int argc, char *argv[], char *envp[]) { if (argc < 2) { fprintf(stderr, "usage: %s <execv args>\n", argv[0]); exit(1); } cap_t needed = cap_from_text("cap_setpcap=ep"); if (cap_set_proc(needed) != 0) { perror("cap_set_proc failed"); exit(1); } int cap = 0; int set; while ((set = prctl(PR_CAPBSET_READ, cap)) >= 0) { if (set && prctl(PR_CAPBSET_DROP, cap)) { fprintf(stderr, "failed to drop bset capability: %s\n", cap_to_name(cap)); exit(1); } cap++; } if (prctl(PR_SET_SECUREBITS, 0x2e /* magic combination */)) { perror("unable lock secure-bits"); exit(1); } fprintf(stderr, "[feeling powerless]\n"); execve(argv[1], argv + 1, envp); fprintf(stderr, "[execve(\"%s\",...) failed - try something else.]\n", argv[1]); exit(1); } //---- cut here 8< ----- > I have no problem with expressing this in a fine grained manner internally > to the kernel but the user space interface needs to be atomic so that > we can enable this all without privilege. I'm not clear on the need for this specific detail. > Further I may be off but I think the implementation would be more > challenging than what I have already posted. �That doesn't mean it > won't be more useful long term. [Not sure I followed this bit.] I can see a desire to block luser -> luser transitions being a good thing, but not because it has anything to do with privilege. Cheers [and happy New Year!] Andrew > > Eric > -- > To unsubscribe from this list: send the line "unsubscribe linux-security-module" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at �http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Casey Schaufler on 1 Jan 2010 16:40
Eric W. Biederman wrote: > Alan Cox <alan(a)lxorguk.ukuu.org.uk> writes: > > >>> - unprivileged process took action to prevent gaining a capability. >>> - exec'd suid sendmail. >>> - sendmail took action as root because it could not become someone else. >>> >> Which is a classic bug and replicated historically in cpu time, quota and >> other similar "remove rights and then .." attacks. >> > > Exactly. The problem that most limits the evolution of the unix > userspace API for ordinary processes. I want a per process disable so > I can use advanced features of the API without being root (or a subset > of root). > And why don't you look into using the security model provided to accomplish your goals rather than decrying the precise semantics? Look at what you just said. You want to provide a mechanism that does what the capabilities mechanism does, but you don't want it to be the capabilities mechanism because what the capabilities mechanism does is bad. >>> I would like to trivially stop that entire class of exploit by making >>> execing a suid ( or equivalent ) executable impossible. >>> The setuid mechanism is not an exploit. It is a component of the security policy. If you take it out you must introduce an alternative of equal or greater power. >> Fine the LSM modules can already build such policies or you can add a new >> LSM for it - it doesn't need whacky one off extensions to prctl. >> > > No it needs a proper system call. no_suid_for_me_and_my_children(). > Spelled nosuid to keep from breaking peoples fingers. > This is a misguided notion. It assumes that the behavior of all applications that might be execed are known in advance. If that is the case, it's pretty silly to use a restriction like this. >> Of course you could also have an LSM which undoes restrictions on suid >> apps instead. Thats an equally valid model, just don't load both at once >> and don't assume you have the one true model. >> > > Alan what are you talking about? LSMs are not allowed to remove > restrictions. > Sure. Not that it would be hard to do so. And have a careful look at the recent discussions on checkpoint/restart. > You are quite right that my initial patch is a bit hacky, I am doing > my development in the open, proving that the concept can be sanely > implemented with very little code, and getting feedback from people > who know the area of code better than I do. I know development in the > open and not having everything perfect and committed to before you > submit a patch is a strange concept on linux-kernel, but I am trying > it out. > > My target audience here are application developers. Not professional > system administrators, not distribution maintainers, and certainly > not professional security trolls. > Application developers have historically been intolerant of systems that change their security policy on the fly. No, let me say what I really mean. They hate them with a flaming passion. Sometimes the system requirements make it necessary, but please don't think the application developers will thank you for it. Application developers want systems that work the way the man pages say they work. They do not want additional or conditional restrictions. How many commercial applications start their installation instructions with "disable SELinux"? (Hint: lots) > I am about removing an impediment from the unix API for those > applications that don't need it so they can use features that would > otherwise be reserved to root and only root, because those features > can be used to addle suid applications. > > I am sick and fed up with the conversations that go: > - I want to do X. > - X has been implemented. > - Sorry I can't use X as implemented because you have to be root to > use X. > Exasperated sigh. Privileged operations are privileged for a reason, not always a good reason mind you, but a reason nonetheless. If your application developers want to do things that require privilege you need to teach them how to write privileged programs safely. We've been working on exotic variations of system controls for decades and in the end your programmers have to write decent code because we haven't yet come up with a way to make all the things that people want their programs to do safe. > In this case X was the network namespace, which for non-root > users happens to act just like the proposed disable_network. > > Putting something in an LSM versus anywhere else in the kernel still > pollutes the pool and we still have to maintain it forever. So my > preference is for something small, trivial, that people can easily > audit. > > I am not satisfied with my patch to disable suid yet, but it does > look simple and in the right ballpark. It certainly needs better > integration with securebits and the like. > > So Alan would you please give some constructive criticism about: > - Why this is a bad idea. > It is a bad idea because the setuid mechanism is a core component of the Linux base security policy and changing this makes many security cognizant applications function in ways they are not intended to and may result in unintended and undesired information flows. > - How to implement this so it is available to application developers > in general. > If what your application developers want to do requires privilege today you need to upgrade your developers to the point where they can be trusted to write privileged programs. > As I see and I may be wrong the LSM and the security modules that > exist today are useless unless you control the entire machine the > kernel runs on. Which applications short of Oracle do not. > Duh? We're talking system level security, are we not? > Personally I think I am on the sent of a good general feature that > makes sense, is useful in a lot of situations, is useful to a lot of > different people, and is useful in a lot of different ways. > > Anything we merge into the mainstream kernel we have to maintain > forever, LSM or core feature. I think this is a good backwards > compatible feature that removes impediments to forward compatibility. > I think that this is a well meant but ill conceived feature. I think that if you could get in your wayback machine and talk Ken and Dennis out of implementing setuid and into doing something else instead you might have a large number of fans, even among "security trools". The feature has good attributes and bad, but it is essential to application developers the world over that is be consistent. > Eric > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |