From: ebiederm@xmission.com (Eric W. Biederman)
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Arnd Bergmann <arnd@arndb.de>, gnomes@lxorguk.ukuu.org.uk, teg@jklm.no,
        jkosina@suse.cz, luto@amacapital.net, linux-kernel@vger.kernel.org,
        daniel@zonque.org, dh.herrmann@gmail.com, tixxdz@opendz.org
References: <20150413190350.GA9485@kroah.com>
	<8738434yjk.fsf@x220.int.ebiederm.org>
	<87lhhv36je.fsf@x220.int.ebiederm.org>
	<20150414175534.GB3974@kroah.com>
Date: Tue, 21 Apr 2015 16:06:15 -0500
In-Reply-To: <20150414175534.GB3974@kroah.com> (Greg Kroah-Hartman's message
	of "Tue, 14 Apr 2015 19:55:34 +0200")
Message-ID: <87oamhmbso.fsf_-_@x220.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Issues with capability bits and meta-data in kdbus
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2970
Lines: 72

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