[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150427130147.GA5315@dztty>
Date: Mon, 27 Apr 2015 14:01:47 +0100
From: Djalal Harouni <tixxdz@...ndz.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
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>
Subject: Re: Sharing credentials in general (Re: [GIT PULL] kdbus for 4.1-rc1)
On Thu, Apr 23, 2015 at 12:41:18PM -0700, Andy Lutomirski wrote:
> On Thu, Apr 23, 2015 at 11:48 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > On Thu, Apr 23, 2015 at 10:57 AM, Linus Torvalds
[...]
> Objection 2: There's a difference between the printer daemon knowing
> that Angry Penguins has general permission to print and an explicit
> assertion by Angry Penguins of its permission to print. Suppose that
> printing is implemented by having Angry Penguins call the method Write
> on some kdbus thing. Suppose further that changing root's password is
> implemented by having the caller call the method Write on some other
> kdbus thing. Before changing the password, the password daemon makes
> sure that the caller (or the caller's kdbus conn or whatever) has
> password-changing permissions. Before printing, the printer daemon
> makes sure that the caller has printing permissions.
>
> In kdbus, this is IMO a big problem. See, I can try to find some
> setuid root program that takes a printer object as input (however
> kdbus might do this -- presumably it would be an object name) and
> calls Write to print some diagnostic thing. Now I just feed it the
> password-changing thingy as input and I can get it to "print" to the
> root password. Oops.
This will not only introduce complexity, it is formulated for a
"supposed" problem, and even if this problem exists, the fix _should_
be simple, no reason to add the extra complexity.
A suid root program that takes objects from input without assuming that
the unprivileged user has provided this, is a bogus program and the fix
should be at this layer, _not_ introduce extra layers...
The same thing can be applied on every other part of the kernel, what if
a suid program takes some input, constructs objects/structs based on
that, and makes a direct syscall or one through a library into another
part of the kernel ? I don't see why it is a problem for kdbus since
this supposed problem can affect every major part of the kernel. If there
is something to fix here, then sure it is not at this level.
Thanks!
--
Djalal Harouni
http://opendz.org
--
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/
Powered by blists - more mailing lists