LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH 0/2] capabilities
@ 2004-05-12  3:24 Andy Lutomirski
  2004-05-12  3:44 ` Chris Wright
  2004-05-12 23:41 ` Andrew Morton
  0 siblings, 2 replies; 6+ messages in thread
From: Andy Lutomirski @ 2004-05-12  3:24 UTC (permalink / raw)
  To: akpm, chrisw, linux-kernel; +Cc: luto

This reintroduces useful capabilities.

In this model, the inheritable mask is a limit on what capabilities
the task or any of its children may have.  Permitted and effective masks
have their old meanings.

Init gets all capabilities (even CAP_SETPCAP) since it seems absurd to do
otherwise.

Part 1 shouldn't change user-visible behavior; it just moves the vfs
capability logic into fs/exec.c (where it IMHO belongs) and the setuid
logic into apply_creds (where it IMHO belongs).  I made no effort to
make apply_creds pretty since it all gets deleted in the next patch
anyway.

Part 2 redoes the capability logic.

This code is paranoid about setuid.  A later patch will allow that to
be overridden by a sysctl so that securelevel can be done usefully.

I left cap_bset in, even though I can't see a use for it anymore.

I put some user tools at http://www.stanford.edu/~luto/cap/; I've used
themn to exercise this code somewhat.

It applies to 2.6.6-mm1.  It does _not_ apply to 2.6.6 vanilla, but the fix
should be trivial (it conflicts with something in fs/exec.c).  It will not
apply to earlier versions, as it depends on the compute_creds race fix.

Please let me know what you think and if you see any holes in this code
or possibilities of exposing / introducing bugs in other programs (think
Sendmail bug).

This should also eliminate the Oracle magic-group mess :)

Andrew- is this sufficiently non-scary for -mm?

Where this is going:
There is probably some dead code now in sys_capset.  I'll check on that.
Also, I have an ext3 xattr caps patch lying around somewhere.  I can try
to get it working again.

--Andy



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/2] capabilities
  2004-05-12  3:24 [PATCH 0/2] capabilities Andy Lutomirski
@ 2004-05-12  3:44 ` Chris Wright
  2004-05-12 23:41 ` Andrew Morton
  1 sibling, 0 replies; 6+ messages in thread
From: Chris Wright @ 2004-05-12  3:44 UTC (permalink / raw)
  To: Andy Lutomirski; +Cc: akpm, chrisw, linux-kernel

* Andy Lutomirski (luto@myrealbox.com) wrote:
> This reintroduces useful capabilities.

Thanks for doing this Andy.  I'd like to give it a close look, but won't
have any time until tomorrow.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/2] capabilities
  2004-05-12  3:24 [PATCH 0/2] capabilities Andy Lutomirski
  2004-05-12  3:44 ` Chris Wright
@ 2004-05-12 23:41 ` Andrew Morton
  2004-05-13  1:50   ` Andy Lutomirski
  1 sibling, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2004-05-12 23:41 UTC (permalink / raw)
  To: Andy Lutomirski; +Cc: chrisw, linux-kernel, luto

Andy Lutomirski <luto@myrealbox.com> wrote:
>
> This reintroduces useful capabilities.
> 

What if there are existing applications which are deliberately or
inadvertently relying upon the current behaviour?  That seems unlikely, but
the consequences are gruesome.

If I'm right in this concern, the fixed behaviour should be opt-in.  That
could be via a new prctl() thingy but I think it would be better to do it
via a kernel boot parameter.  Because long-term we should have the fixed
semantics and we should not be making people change userspace for some
transient 2.6-only kernel behaviour.

> Andrew- is this sufficiently non-scary for -mm?

Scares the shit out of me, frankly ;)


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/2] capabilities
  2004-05-12 23:41 ` Andrew Morton
@ 2004-05-13  1:50   ` Andy Lutomirski
  2004-05-13  1:55     ` Andrew Morton
  2004-05-15  0:00     ` Paul Jakma
  0 siblings, 2 replies; 6+ messages in thread
From: Andy Lutomirski @ 2004-05-13  1:50 UTC (permalink / raw)
  To: Andrew Morton; +Cc: chrisw, linux-kernel, luto

Andrew Morton wrote:
> Andy Lutomirski <luto@myrealbox.com> wrote:
> 
>>This reintroduces useful capabilities.
>>
> 
> 
> What if there are existing applications which are deliberately or
> inadvertently relying upon the current behaviour?  That seems unlikely, but
> the consequences are gruesome.

Like something that turns KEEPCAPS on then setuid()s then executes an 
untrusted program?  It's obviously wrong, but it's secure currently 
since the exec wipes capabilities.  And no one would notice.  Ugh!

> 
> If I'm right in this concern, the fixed behaviour should be opt-in.  That
> could be via a new prctl() thingy but I think it would be better to do it
> via a kernel boot parameter.  Because long-term we should have the fixed
> semantics and we should not be making people change userspace for some
> transient 2.6-only kernel behaviour.

The prctl would defeat the purpose (imagine if bash forgot the prctl -- 
then the whole thing is pointless).  I'll cook up the boot parameter in 
the next couple days (probably with a config option and some kind of 
warning that the old behavior is deprecated).  Is it a problem if I make 
the changes to init's state unconditional?  (I still don't see why 
CAP_SETPCAP is dangerous for root to have...)

The only concern is that some new code relies on the new inheritable 
semantics.  That shouldn't be so bad, though, since that's just an extra 
precaution (if there are insecure setuid binaries around, you already 
have problems).


--Andy


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/2] capabilities
  2004-05-13  1:50   ` Andy Lutomirski
@ 2004-05-13  1:55     ` Andrew Morton
  2004-05-15  0:00     ` Paul Jakma
  1 sibling, 0 replies; 6+ messages in thread
From: Andrew Morton @ 2004-05-13  1:55 UTC (permalink / raw)
  To: Andy Lutomirski; +Cc: chrisw, linux-kernel, luto

Andy Lutomirski <luto@myrealbox.com> wrote:
>
> > 
> > What if there are existing applications which are deliberately or
> > inadvertently relying upon the current behaviour?  That seems unlikely, but
> > the consequences are gruesome.
> 
> Like something that turns KEEPCAPS on then setuid()s then executes an 
> untrusted program?

Or if it simply has caps and then does exec.

> > If I'm right in this concern, the fixed behaviour should be opt-in.  That
> > could be via a new prctl() thingy but I think it would be better to do it
> > via a kernel boot parameter.  Because long-term we should have the fixed
> > semantics and we should not be making people change userspace for some
> > transient 2.6-only kernel behaviour.
> 
> The prctl would defeat the purpose (imagine if bash forgot the prctl -- 
> then the whole thing is pointless).

yup, lots of apps would need to be changed to interface with something
which won't be present in 2.8 kernels.

>  I'll cook up the boot parameter in 
> the next couple days (probably with a config option and some kind of 
> warning that the old behavior is deprecated).

I wouldn't bother with a config option.

>  Is it a problem if I make 
> the changes to init's state unconditional?  (I still don't see why 
> CAP_SETPCAP is dangerous for root to have...)

I'd be more comfortable (ie: comfort level non-zero) if there was zero
behaviour change if the boot option isn't enabled.

> The only concern is that some new code relies on the new inheritable 
> semantics.  That shouldn't be so bad, though, since that's just an extra 
> precaution (if there are insecure setuid binaries around, you already 
> have problems).

Yes, we can live with that.  The price of prior sins.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH 0/2] capabilities
  2004-05-13  1:50   ` Andy Lutomirski
  2004-05-13  1:55     ` Andrew Morton
@ 2004-05-15  0:00     ` Paul Jakma
  1 sibling, 0 replies; 6+ messages in thread
From: Paul Jakma @ 2004-05-15  0:00 UTC (permalink / raw)
  To: Andy Lutomirski; +Cc: Andrew Morton, chrisw, linux-kernel

On Wed, 12 May 2004, Andy Lutomirski wrote:

> Like something that turns KEEPCAPS on then setuid()s then executes
> an untrusted program?  It's obviously wrong, but it's secure
> currently since the exec wipes capabilities.  And no one would
> notice.  Ugh!

Definitely wrong. 

> The prctl would defeat the purpose (imagine if bash forgot the
> prctl -- then the whole thing is pointless).

Capabilities aware programmes are most likely already setting
PR_SET_KEEPCAPS anyway if they're doing anything half-fancy. Another 
prctl() wont hurt too much if it is the only way to guarantee 
backward compatible security (?).

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam@dishone.st
Fortune:
"I go on working for the same reason a hen goes on laying eggs."
- H. L. Mencken

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-05-15  0:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-12  3:24 [PATCH 0/2] capabilities Andy Lutomirski
2004-05-12  3:44 ` Chris Wright
2004-05-12 23:41 ` Andrew Morton
2004-05-13  1:50   ` Andy Lutomirski
2004-05-13  1:55     ` Andrew Morton
2004-05-15  0:00     ` Paul Jakma

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).