Replacing setuid with file capabilities

[Kees Cook]

Hi Andrea,

On Thu, Mar 29, 2012 at 04:29:29PM +0200, Andrea Corbellini wrote:
> As many of you already know, there are some setuid executables in Ubuntu
> that perform very specific tasks and do not need many special privileges
> (ping and traceroute are just two examples). My proposal is to remove
> their setuid flag and set the file capabilities they need through
> setcap(8). This will indeed reduce the risk of privilege escalation.

The good news is that the bulk of these tools immediately drop their
privs. A while back, some source checking was done to see where things
stood, and this was produced to help track it, and needs further work:
https://wiki.ubuntu.com/Security/Investigation/Setuid

While dropping privs early helps mitigate target binary flaws, it doesn't
help loader flaws:
http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-3856.html

And while it looks like a good idea to use filesystem capabilities,
there are, unfortunately, a number of things blocking that adoption:
https://wiki.ubuntu.com/Security/FilesystemCapabilties

As Serge mentioned, filesystem support is a big deal. While a package
manager could be taught to retain setuid bits for programs that can run
in 'dual mode' (detecting either fscaps or setuid), if those file systems
are exported on NFS to clients, we lose. I think that's a small use-case,
though. A big use-case is overlay filesystems, which are heavily used
(like, in the Ubuntu installer), and if those don't pass the attrs
correctly, we lose again.

Beyond that, there are the package management blockers (outlined in
the URL above). Various tools need to support the attrs correctly,
and dpkg needs to grow an entire chunk of logic for dealing with it.

And for the reasons Marc pointed to (Brad's run down on how almost all
capabilities are equivalent to full root access, and Solar's point that
adding caps to a tool without its knowledge can be dangerous), changing
the tools correctly is important too. Holding caps should be treated
as being just as dangerous as being setuid. I think, if it's to be done
right, every setuid tool needs to operate in a dual-mode where it examines
its state and retains only the caps it needs, and then drops those as soon
as possible, in addition to dropping setuidness after keeping the caps
it needs. In this way, they can run either as setuid or as fscap-using
tools, which will likely be up to the package manager at install time.

> I think this is the right time to start discussing about this feature
> because 12.10 is four releases away from the next LTS and the risk of
> committing serious mistakes is lower.
> 
> So, what do you think? Is it something that we could do for the
> Q-series?

In my opinion, it's been discussed a great deal already. Without the
filesystem support and the archiving tool support, it's not fruitful to
start on the package manager support.

Beyond those things, I think it would be cool to see the "dual-mode"
logic added to all the tools so that if system owners choose to drop
the setuid bit and add the fscaps, the program will behave as safely as
possible. And that work doesn't need a session -- it needs patches. :)

-Kees

-- 
Kees Cook