[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Nov 2010 14:18:33 -0500
From: Steve Grubb <sgrubb@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Kees Cook <kees@...ntu.com>
Subject: Re: filesystem capabilities
On Wednesday, November 10, 2010 01:06:29 pm Kees Cook wrote:
> On Mon, Nov 08, 2010 at 12:01:29PM -0500, Steve Grubb wrote:
> > >While in general this is a good idea, there are issues with it,
> > >in arbitrary order:
> > >
> > >- Some currently-SUID programs are aware of them being (potentially)
> > >SUID, and will drop the "more privileged" euid when it is no longer
> > >needed, but they will probably not be aware of them possessing
> > >capabilities.
> >
> > This is an artifact of having a capabilities library that takes several
> > lines of code to do anything. It is more correct to check for
> > capabilities that trusting that euid means that you have certain powers.
> > In my opinion, a lot of this code should be cleaned up so that its
> > correct.
>
> Right, it's not just a matter of dropping setuid bits and adding fscaps;
> these tools each need to be changed to understand fscaps and correctly drop
> privs. Which is especially true for "mixed" environments where the code
> could run _either_ as setuid or with fscaps. Building that logic into the
> cap library (which ever one) is the plan, as I understand.
Not that I know of. The library cannot know what the application's threat model is.
The library can make it simple to access the correct things. The following should be
the model that I think solves the problem for either setuid or fs based capabilities.
Assuming you needed CAP_CHOWN:
capng_get_caps_process();
switch (capng_have_capabilities(CAPNG_SELECT_CAPS)) {
case CAPNG_FULL:
capng_clear(CAPNG_SELECT_BOTH);
capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED,
CAP_CHOWN);
if (capng_apply(CAPNG_SELECT_BOTH))
exit(0);
break;
case CAPNG_PARTIAL:
// Paranoid double check that we have what we expect
if (capng_have_capability(CAPNG_EFFECTIVE, CAP_CHOWN)==0)
exit(0);
// Now to make sure that is ALL that we have...let's drop it and
// see if we are empty
capng_update(CAPNG_DROP, CAPNG_EFFECTIVE|CAPNG_PERMITTED,
CAP_CHOWN);
if (capng_have_capabilities(CAPNG_SELECT_CAPS) != CAPNG_NONE)
exit(0);
break;
case CAPNG_FAIL:
case CAPNG_NONE:
exit(0);
}
// At this point both setuid and fs based caps should have the same thing
> > The intent of this project is to get the patches and user space work
> > done. We know that just setting the bit is not all that has to be done.
>
> Yup, and Debian and Ubuntu have even further to go since their userspace
> and package manager don't even handle xattrs. It would be nice if upstream
> tar took the xattr patches. Steve, are there any plans to make that happen?
You can lead a horse to water, but you cannot make them drink.
http://lists.gnu.org/archive/html/bug-tar/2006-08/msg00004.html
We did our part. Its up to them to accept the patch or keep talking about it. Reading
the thread, it sounded like they were going to take it. No idea why they decided
against it unless it was seen as a Linux only patch. You might poke them and ask why
in the last 4 years they never took the patch. Of course since then we've maintained
the patch against current tar releases, so they would want a newer patch.
-Steve
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
