Re: [PATCH 0/2] capabilities

[Andy Lutomirski]

Andrew Morton wrote:
> Andy Lutomirski <luto@xxxxxxxxxxxxx> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/