Messages in this thread | | | Date | Fri, 13 Mar 2015 06:24:28 -0700 | Subject | Re: [RFC] capabilities: Ambient capabilities | From | "Andrew G. Morgan" <> |
| |
> It's to preserve the invariant that pA is always a subset of pI.
But since a user can always raise a bit in pI if it is present in pP, what does this invariant add to your model other than inconvenience?
>> I'm also unclear how you can turn off this new 'feature' for a process >> tree? As it is, the code creates an exploit path for a capable (pP != >> 0) program with an exploitable flaw to create a privilege escalation >> for an arbitrary child program. > > Huh? If you exploit the parent, you already win. Yes, if a kiddie > injects shellcode that does system("/bin/bash") into some pP != 0 > program, they don't actually elevate their privileges. On the other > hand, by the time an attacker injected shellcode for: > > prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, CAP_SYS_ADMIN); > system("/bin/bash");
Let's call the above two lines [a] and [b]. With this patch, you are encouraging folk to write programs that contain a line like [a] already. So, yes, I am saying that you are creating an exploitable path in these programs that says if someone can inject system("/bin/bash") into these programs they can get a new (because of this patch) privilege escalation.
In the prevailing model, this kind of privilege escalation (resulting from naive inheritance) is designed out. I recognize that you want to add it back in, but I am concerned that you are not allowing for the possibility that some folk might still want to still be able to prevent it.
> into a target, they can already do whatever they want. > >> While I understand that everyone >> 'knows what they are doing' in implementing this change, I'm convinced >> that folk that are up to no good also do... Why not provide a lockable >> secure bit to selectively disable this support? > > Show me a legitimate use case and I'll gladly implement a secure bit.
Thanks. I was kind of hoping that you would add a lockable secure bit that defaults this support to off, but can be used to turn it on with or without a lock. That way, you can avoid disturbing the legacy defaults (no surprises).
> In the mean time, I don't even believe that there's a legitimate use > for any of the other secure bits (except keepcaps, and I don't know > why that's a securebit in the first place).
Those bits currently make it possible to run a subsystem with no [set]uid-0 support in its process tree.
> In the mean time, see CVE-2014-3215 for an example of why securebits > are probably more trouble than they're worth.
I think it is safe to say that naive privilege inheritance has a fair track record of being exploited orders of magnitude more frequently than this. After all, these are the reasons LD_PRELOAD and shell script setuid bits are suppressed.
Cheers
Andrew
| |