Quoting Kees Cook (email@example.com):
> 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:
> While dropping privs early helps mitigate target binary flaws, it doesn't
> help loader flaws:
> And while it looks like a good idea to use filesystem capabilities,
> there are, unfortunately, a number of things blocking that adoption:
> 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
As per the recent LWN article, I do hope to start keeping a closer eye
on this, and perhaps go further in the direction of CAP_SYSLOG (with
small distinct capabilities which continue to be implied by the larger
> adding caps to a tool without its knowledge can be dangerous), changing
As can taking caps away without its knowledge
Absolutely, we need
to audit every program we consider switching over.
> 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.
I wonder if a simple API might be helpful. Top of my head while in the
midst of a long unrelated debugging session; probably has holes, might
even be completely wrong. But:
* @caps is a list of capabilites which the caller will need
* at some point
* If caller is setuid-root, it will store @caps in its permitted
* set, request keeping its capability, clear pE, and switch all uids
* to its real uid.
* If caller is non-root, and does not have all the capabilities in
* @caps, return with error
* If caller is non-root and has at least all the capabilities in
* @caps, drop all capabilities from pE, drop all capabilities not
* int @caps from pP.
* Do we want this to take an optional uid to switch to, instead of
* the real uid?
int cap_temp_drop_caps(int ncaps, cap_t *caps);
* activate the capabilities in @caps in pE.
* @caps must be a subset of pP, else return error.
int cap_regain_caps(int ncaps, cap_t *caps);
* clear pE
* drop all capabilities permanently
Because I'm plenty familiar with how unwieldy libcap2 API is
But then, maybe we're just re-inventing capng.
And there is one more problem - much of this software wants to work
on systems other than linux. See the old usenix login; article about
safe setuid... It's complicated enough as is, without adding
linux-specific hacks. I'm not sure how we cleanly finagle the
above API into such software.
ubuntu-server mailing list
More info: https://wiki.ubuntu.com/ServerTeam