Messages in this thread | | | From | (Eric W. Biederman) | Date | Tue, 21 Apr 2015 16:06:15 -0500 | Subject | Issues with capability bits and meta-data in kdbus |
| |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Mon, Apr 13, 2015 at 07:19:49PM -0500, Eric W. Biederman wrote: >> ebiederm@xmission.com (Eric W. Biederman) writes: >> >> > And the code that transfers the meta-data is wrong. >> >> In fact it is worse than I thought. > > Please see the email response I just wrote to Andy about this, it should > address these misconceptions.
Nothing has changed my analysis of the kdbus code.
Hopefully now that I have made some semblance of getting some rest and have a little bit of time I can explain the issues that I see. I will be focusing on user namespaces and capability bits as that is my area of the kernel.
- The userspace interface for capability bits has a version number that determines the quantity and the meaning of the bits, kdbus does not pass that number to userspace.
- There is a well defined translation of capability bits between user namespaces kdbus does not perform that translation.
- Access to the capability bits is guarded with PTRACE_MAY_READ kdbus does not honor that and thus leaks information.
- Usage of the capability bits by userspace is a layering violation.
- The layering violation results in a privilege escalation (by definiton) whenever userspace uses the presence of the capability bits to allow anything.
- Another kind of privilege escalation happens when userspace makes a decision based on the abscense of in kernel capability bits.
The only safe way for userspace to use the kernel capability bits is to decide which small handful of processes need the bits. Let those processes be what implements userspace policy and drop the capabilities from everything else.
With bugs at every layer of the implementation stack from implementation to design I concluded earlier that the code that transfers these capabilities is not at all mature or ready to be merged. Which is why I asked for the code to be left for later until someone would pay attention to it properly.
I will add that when playing with the unix security mechanism the design has to be done very carefully, as the system is fragile and certain kinds of changes modify existing tested designs into insecure code. I fail to see any of that kind of needed care being applied to the design of the kdbus mechanisms.
My conclusion is that the design of the meta-data passing code is fundamentally broken. The issues I have observed with the kernel capability bits apply to all of the other meta-data except that meta-data that unix domain sockets already pass. The privilege escalation issues are fundamentally unfixable, and apply in general.
As this is fundamental to kdbus, kdbus is apparently fundmanetally broken by design.
Eric
| |