linux-kernel - Re: Issues with capability bits and meta-data in kdbus

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]

Date:	Wed, 22 Apr 2015 13:41:05 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.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>,
	Andy Lutomirski <luto@...capital.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: Issues with capability bits and meta-data in kdbus

Hi

On Wed, Apr 22, 2015 at 3:30 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>> - There is a well defined translation of capability bits between user
>>   namespaces kdbus does not perform that translation.
>
> Now this looks like a big oversight, and serious.
>
> If you have a capability inside a lower namespace, and can fool the
> other end of a kdbus connection into thinking that you have that
> capability globally, then that sounds like a very obvious and bad
> security issue. This needs fixing. That said, it's likely a fairly
> simple fix.

kdbus drops capability items if we cross user-namespaces. This
security issue was fixed in v2.

I think the translation Eric was referring to, is what cap_capable()
(security/commoncap.c) does. That is, it translates capabilities of
parent namespaces into its child namespaces (making the parent
privileged in the child namespace). Right now, we don't do this.
Instead, we drop the item, so the receiver knows that the information
could not be gathered (unlike a zeroed capability item, which means
the sender does not have the capabilities).

I have an experimental patch to support translation [1]. However, I
dislike copying the code from security/ into kdbus. So if we introduce
translation later on, I'd like to figure out with LSM developers how
to do this best.

Also note that /proc does not do any translation on its own, which
makes cap_get_pid() tricky to use.

>> - Access to the capability bits is guarded with PTRACE_MAY_READ
>>   kdbus does not honor that and thus leaks information.
>
> Now, this is likely not a real problem.
>
> Yes, when you try to read other processes capabilities, you need
> PTRACE_MAY_READ to see them. HOWEVER, that's not really what a kdbus
> message would do - it doesn't "read somebody elses capabilities". When
> you do a kdbus write, you export your *own* capabilities. If you don't
> want others to know what privileges you have, then you shouldn't be
> using kdbus.

I fully agree.

And to clear things up: there is no such PTRACE_MODE_READ protection
for capability bits in /proc.

Thanks!
David

[1] http://cgit.freedesktop.org/~dvdhrm/linux/commit/?h=kdbus&id=894085ff39afc653ed711102fa698d937818ce1f
--
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/