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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 23 Apr 2015 10:57:37 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	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 Thu, Apr 23, 2015 at 10:16 AM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>>
>>  - starttime, cmdline, and possibly other pieces of metadata are also
>> problematic.  I think starttime is especially bad because it both
>> breaks CRIU and is IMO completely unnecessary -- I sent out draft
>> "highpid" patches a while ago to give a much better alternative that
>> isn't racy and won't break CRIU.  But cmdline is also IMO ridiculous.
>
> starttime was removed a while ago, are you sure you are looking at the
> latest code?
>
> cmdline has been discussed and it really helps with debugging.
> Decisions aren't being made based on it.

Quite frankly, I personally find cmdline/comm etc *much* worse than
sending the capabilities.

The whole notion of knowing "the other end is root" (or more
specifically some capability like "the other end can access raw
hardware") I think is a thing that absolutely makes sense in any
communication channel. I really don't even see why it would be
conditional. I mean, it's not exactly a secret anyway, and it just
makes *sense* for any protocol that may end up doing operations _for_
the recipient.

Same goes for uid etc - if you are implementing a service daemon, the
uid of the requester sure as hell makes a ton of difference in what
you might want to expose. Things like "does this user have access
rights to the printer?" are very natural questions to ask.

So I really don't understand why that part is even controversial.
kdbus wasn't meant to be some generic IPC mechanism. It is meant as a
way to talk to system daemons.

So the whole "capabilities and user information" is really to me a
non-issue. It's clearly required information, and if you don't want to
expose it, you damn well have absolutely *zero* business talking to
system daemons.

Really, it's that simple.

But things like "comm" and the cmdline? That makes me nervous. There
are real privacy issues there. Sure, maybe you think it's useful for
debugging, but the very fact that you think it's useful for debugging
makes me suspect you might be logging it (for future debugging). And
quite frankly, I don't think you should be logging things like that.
Yes, yes, if you're a system admin, you can find those things out, but
they should *not* be something that you just end up logging by mistake
or because "it's easy and all the information is right there".

If somebody is printing something, it shouldn't matter if it's "lpr"
or "firefox http://horses.and.trannyporn.my.little.pony.com/" that
does the printing.

And you can go "but we don't log it" all you want. It's still a bad
idea. Sane people should refuse to allow a system service to see those
kinds of things by default, for a very simple reason: it's none of
their business.

So I'd suggest just getting rid of "tid_comm/pid_comm/cmdline". There
is no possible valid excuse for them. They aren't trustworthy anyway
(ie a real attacker can obfuscate them easily), and they *are*
potentially sensitive.

[ Side note: the tid_comm/pid_comm ones depend on TASK_COMM_LEN
anyway, which might change. a 16-byte command name used to be insanely
long in the traditional unix environment, but these days it's actually
regularly a truncated name due to programs called things like
"gnome-shell-extension-prefs" or
"abrt-action-generate-core-backtrace". ]

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