linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrWn8shMOvY3jo0yO_eeLWo47fqwoWX3Qn-2AzdzGCG5Ew@mail.gmail.com>
Date:	Mon, 13 Apr 2015 17:34:38 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Mon, Apr 13, 2015 at 5:19 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> ebiederm@...ssion.com (Eric W. Biederman) writes:
>
>> Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
>>
>>> The following changes since commit 9eccca0843205f87c00404b663188b88eb248051:
>>>
>>>   Linux 4.0-rc3 (2015-03-08 16:09:09 -0700)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ tags/kdbus-4.1-rc1
>>>
>>> for you to fetch changes up to 9fb9cd0f4434a23487b6ef3237e733afae90e336:
>>>
>>>   kdbus: avoid the use of struct timespec (2015-04-10 14:34:53 +0200)
>>>
>>> ----------------------------------------------------------------
>>> kdbus for 4.1-rc1
>>>
>>> Here's the kdbus pull request for 4.1-rc1.
>>>
>>> It's been under development for many years now, and been in linux-next
>>> for many months, and has undergone loads of testing a review and even a few
>>> good arguments.  It comes with full documentation and tests.
>>
>>> There has been a few complaints about the code, notably from people who
>>> don't like the use of metadata in the bus messages.  That is actually
>>> one of the main features here, as we can get this data in a secure and
>>> reliable way, and it's something that userspace requires today.  So
>>> while it does look "odd" to people who are not familiar with dbus, this
>>> is something that finally fixes a number of almost unfixable races in
>>> the current dbus implementations.
>>
>> And the code that transfers the meta-data is wrong.
>
> In fact it is worse than I thought.
>
> With an userspace application able to give meaning to any of the bits of
> meta-data that are passed (capabilities, cgroup, security labels, etc)
> that in the fullness of time dropping in them will grant you more
> permissions somewhere.
>
> Which means that it becomes impossible to change anything.  Impossible
> to jail anything.  It in fact becomes impossible to do anything right.
>
> Which means the ultimate result of the direction kdbus is going is a
> world where nothing can be done without introducing a security issue or
> breaking userspace.
>
> So as far as I can tell kdbus has a fundamental design flaw.
>
> My apologies for being the bearer of bad news.
>

I agree here.  I cannot overstate the degree to which passing caps
around through metadata is a bad idea.

LSM labels are probably nearly as bad.  Having LSM hooks in kdbus is
one thing, but passing the *raw labels* around and letting userspace
muck with them will cause the policy situation to be incomprehensible.

User code should get simple yes/no answers from LSM policy, not raw data.

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