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]

Date:	Thu, 23 Apr 2015 11:48:58 -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:57 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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.

Hmm. Looking at the code, it strikes me that not only does
kdbus_meta_proc_collect() collect too much, but some of what it
collects it just seems to do *wrong*.

So I agree with collecting user and credential information (obviously
unlike some people ;), but I think the code that does it is just
wrong.

The way to collect user and credential information is very simple: you
look at "file->f_cred".

That's _it_. Nothing more. Maybe you do "get_cred(file->f_cred):" if
you have lifetimes of this after the "struct file" is gone. But you
don't copy the fields individually or willy-nilly.

That "struct cred" reference gets you all you need. It gets you the
supplementary groups. It gets you the capabilities. It gets you the
user and group id's.

And equally importantly, it gets you the namespace so that you can do
conversions to random target namespaces later, when you actually *use*
the information.

There might be some question about whether you should use
"current->cred" or "file->f_cred", but the latter is almost always the
right thing to use when you are doing file operations. The unix
filesystem security model is about permissions at open time, not at
use time.

                         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/