Weekly Edition
Return to the Kernel page
| |||||||||||||
Toward a saner execve()
Contemporary Linux systems allow processes to set up their environments in
any of a number of ways. For various reasons, developers sometimes want
even more flexibility; in particular, they would like to take something
away (filesystem access, network access, capabilities) from a running
process, usually in the name of security. The problem is that such changes
can actually make security worse; as has been seen many times, privileged
programs can be made to do strange and unfortunate things when run in
unexpected environments.
As Andy Lutomirski notes, one response to this problem is to disable setuid semantics as well. But there are a lot of ways for the execve() system call to change a process's privileges which do not involve setuid programs; this is especially true in the presence of security modules. So Andy has proposed a different idea: opt out of execve() instead. To that end, he proposes a new prctl() option (PR_RESTRICT_ME) which could be used to add restrictions to a running process; the first of those is that the process cannot call execve(). Disabling execve() would be mandatory before any other restrictions could be added. But a process running in a restricted mode might still want to run other programs; that's how Linux programs often work. To accommodate that need, Andy has added a new system call, named execve_nosecurity(). This variant of execve() will run the indicated program, but it will perform absolutely no security transitions first. So no setuid, no SELinux type changes, etc. The end result is a system call with functionality similar to simply mapping the program into the caller's address space and running it directly. With execve_nosecurity(), it is not possible to increase privileges by running another program, so it should make the removal of capabilities from running processes safer. This patch should address a number of the concerns developers have had with the restricting of privileges. It's hard to tell for sure, though, because there has been very little in the way of response so far. (Log in to post comments)
Toward a saner execve() Posted Apr 1, 2010 9:58 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
how's execve_nosecurity different from http://lists.grok.org.uk/pipermail/full-disclosure/2004-J... ?
Toward a saner execve() Posted Apr 1, 2010 13:03 UTC (Thu) by cesarb (subscriber, #6266) [Link]
I can see it as different in two ways.
First, it is in the kernel, and would probably share a lot of code with the normal execve(). This would mean it would behave in exactly the same way except in the ways it would behave different on purpose, including any bugs, new features, and bug fixes.
Second, it would allow (as explained in more detail in the linked message) for the new syscall to take the place of execve(), without having to use ugly (and potentially brittle) LD_PRELOAD or ptrace tricks.
The second reason seems much more compelling than the first.
Toward a saner execve() Posted Apr 1, 2010 22:32 UTC (Thu) by quotemstr (subscriber, #45331) [Link] execve_nosecurity()? That's a god-awful name for the function. It suggests the opposite of what it actually does. Only a kernel developer living in the linux-devel echo chamber could think that name makes a lick of sense.Not that it will matter, because like most Linux-specific pieces of functionality, nobody will use it. It's masturbation by API. It won't actually improve security if nobody calls it. But kernel developers will have to cart around support for this abomination forever, and hell, there's always the risk of there actually being a vulnerability introduced in this seldom-used, lightly-tested code path.
Toward a saner execve() Posted Apr 2, 2010 20:43 UTC (Fri) by nix (subscriber, #2304) [Link]
Quite so. execve_secure() would be a better name. 'nosecurity' only makes
sense if you think of it as 'do not use the security API', which is only something a kernel hacker would even *know* about.
Toward a saner execve() Posted Apr 2, 2010 23:29 UTC (Fri) by eparis123 (guest, #59739) [Link]
Yeah. Unfortunately most of new Linux kernel system call names SUCK.
Toward a saner execve() Posted Apr 9, 2010 14:12 UTC (Fri) by i3839 (guest, #31386) [Link]
So the security mess digs a hole too deep for itself, and wants to make worse for everyone else by adding that awfull systemcall? No thanks.
Just add a prctr() that makes execve() behave like this new execve_nosecurity(), that should do it. Or better, fix up the whole mess so that this whole issue isn't here at all.
If you want to make things more secure, simplify, don't add extra complexion like this.
Bah.
|
|||||||||||||