Quoting Kees Cook ([email protected]): > 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
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 capabilities). > 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. :) Agreed. 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 */ void cap_redrop_caps(void); /* * drop all capabilities permanently */ void cap_perm_drop_caps(void); Because I'm plenty familiar with how unwieldy libcap2 API is otherwise. 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. -serge -- ubuntu-server mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
