FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Server Development

 
 
LinkBack Thread Tools
 
Old 03-29-2012, 02:29 PM
Andrea Corbellini
 
Default Replacing setuid with file capabilities

Hello,

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.

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?


--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 03-29-2012, 04:01 PM
Serge Hallyn
 
Default Replacing setuid with file capabilities

Quoting Andrea Corbellini (corbellini.andrea@gmail.com):
> Hello,
>
> 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.
>
> 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?

One of the things which always blocked this in the past has been
support for non-xattr filesystems, in particular NFS. Perhaps
it's something postinst can tweak based on fs support?

Couldn't hurt to have another session on this at next UDS.

thanks,
-serge

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 03-29-2012, 04:53 PM
Clint Byrum
 
Default Replacing setuid with file capabilities

Excerpts from Serge Hallyn's message of Thu Mar 29 09:01:42 -0700 2012:
> Quoting Andrea Corbellini (corbellini.andrea@gmail.com):
> > Hello,
> >
> > 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.
> >
> > 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?
>
> One of the things which always blocked this in the past has been
> support for non-xattr filesystems, in particular NFS. Perhaps
> it's something postinst can tweak based on fs support?
>
> Couldn't hurt to have another session on this at next UDS.
>

Wouldn't it be simpler to just have apparmor confine these binaries
to their intended setuid-needing capabilities?

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 03-29-2012, 05:08 PM
Marc Deslauriers
 
Default Replacing setuid with file capabilities

On Thu, 2012-03-29 at 09:53 -0700, Clint Byrum wrote:
> Excerpts from Serge Hallyn's message of Thu Mar 29 09:01:42 -0700 2012:
> > Quoting Andrea Corbellini (corbellini.andrea@gmail.com):
> > > Hello,
> > >
> > > 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.
> > >
> > > 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?
> >
> > One of the things which always blocked this in the past has been
> > support for non-xattr filesystems, in particular NFS. Perhaps
> > it's something postinst can tweak based on fs support?
> >
> > Couldn't hurt to have another session on this at next UDS.
> >
>
> Wouldn't it be simpler to just have apparmor confine these binaries
> to their intended setuid-needing capabilities?
>

Please read these first:

http://permalink.gmane.org/gmane.comp.security.oss.general/3719

http://forums.grsecurity.net/viewtopic.php?f=7&t=2522

I'm not convinced we won't be introducing all new vulnerabilities by
trying to remove the setuid flag.

Marc.




--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 03-29-2012, 05:42 PM
Kees Cook
 
Default Replacing setuid with file capabilities

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

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 03-29-2012, 11:22 PM
Serge Hallyn
 
Default Replacing setuid with file capabilities

Quoting Kees Cook (kees@ubuntu.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:
> 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
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 

Thread Tools




All times are GMT. The time now is 07:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org