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:	Tue, 21 Apr 2015 18:54:13 -0700
From:	Andy Lutomirski <luto@...capital.net>
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>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: Issues with capability bits and meta-data in kdbus

On Tue, Apr 21, 2015 at 6:30 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>> - 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.
>
> It's like saying "you need PTRACE_MAY_READ" to be able to read the
> process image of another process. True. But if that other process does
> a "write()" system call, then the written data will contain the data
> from that process. That's how write works.

There's an interesting philosophical question here.

If kdbus were a general purpose IPC tool and if the libraries would
expose nice knobs like "set this flag if and only if you want to
assert CAP_WHATEVER to the server", then maybe this would be okay.

But I don't believe that for a second.  AFAICS sd-bus (maybe the
primary implementation) will always set that flag if for no other
reason than that it *doesn't know* when the client is trying to assert
a capability.  So we'd be giving users a gun which is, in practice,
only ever pointed at the users' feet.

It's a little worse than that, since this gun also shoots
cap_permitted, cap_inheritable, and bset bullets, none of which seem
usable for anything other than foot-shooting even in the best case.
And don't even get me started about some of the other metadata items.

All of this completely ignores the fact that selinux can and does
restrict access to /proc and kdbus will never respect those
restrictions.  Also, I'd like to see us move closer to a world where
real distros set hide_pid=1, and this is a big step in the opposite
direction.

--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/