Toward a saner execve()

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.