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: <20150423193355.GA14545@kroah.com>
Date:	Thu, 23 Apr 2015 21:33:55 +0200
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jiri Kosina <jkosina@...e.cz>,
	David Herrmann <dh.herrmann@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Daniel Mack <daniel@...que.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Thu, Apr 23, 2015 at 12:22:10PM -0700, Andy Lutomirski wrote:
> On Apr 23, 2015 11:56 AM, "Greg Kroah-Hartman"
> <gregkh@...uxfoundation.org> wrote:
> >
> > On Thu, Apr 23, 2015 at 11:04:36AM -0700, Linus Torvalds wrote:
> > > On Thu, Apr 23, 2015 at 10:57 AM, Linus Torvalds
> > > <torvalds@...ux-foundation.org> wrote:
> > > >
> > > > 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 btw, it's not just "this is information that shouldn't be logged".
> > >
> > > It's literally "information that should not *ever* be used". I can
> > > easily see some phone manufacturer deciding to do "value add" by
> > > adding a special case where a special vendor system manager program
> > > gets a back door to some service, because it needs to access the
> > > camera for user identification at login time, so there's some magic
> > >
> > >    if (!strcmp(client->pid_comm, "vendor-login-pr"))
> > >        return ACCESS_OK;
> > >
> > > because "it was the simplest way to do this", and the programmer knew
> > > it was a hack, but he needed to get it working because he had a
> > > deadline yesterday.
> > >
> > > And then somebody figures this out, and makes an app that takes
> > > pictures on your phone surreptitiously.
> > >
> > > No, we can't protect against vendors doing stupid things, but we very
> > > much also shouldn't make the kernel have interfaces that basically
> > > encourage people to do stupid things because they make irrelevant and
> > > wrongheaded data available.
> >
> > Doing access control based on comm and cmdline is horrid, I totally
> > agree.  But right now, any process in the system can read any other
> > process's comm and cmdline value out of /proc today.  So removing it
> > from the metadata is fine for kdbus, I can live with that, but it really
> > isn't "preventing" anything that's not already visible to everyone, so
> > if someone wanting to be "bad" could always still log it or do anything
> > else they wanted with it.
> 
> I feel like a broken record.  This isn't true in general.

Works on my box :)

> Selinux can and, I believe, often does prevent this.

Ok, then the LSM patches for kdbus should be able to also mediate this
as well if needed.  I haven't looked at the LSM kdbus patches in a long
time, so I don't remember exactly what they were looking at.

Again, I don't object to dropping this in kdbus, just confused as this
seemed to me to be something that is always available to all processes
anyway, we weren't adding something previously "hidden".

thanks,

greg k-h
--
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/