linux-kernel - Re: [PATCH 3/3] p9auth: add p9auth driver

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: <20100421143016.GA31880@us.ibm.com>
Date:	Wed, 21 Apr 2010 09:30:16 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Eric Paris <eparis@...hat.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	lkml <linux-kernel@...r.kernel.org>,
	David Howells <dhowells@...hat.com>,
	Ashwin Ganti <ashwin.ganti@...il.com>,
	Greg KH <greg@...ah.com>, rsc@...ch.com, ericvh@...il.com,
	linux-security-module@...r.kernel.org,
	Ron Minnich <rminnich@...il.com>, jt.beard@...il.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrew Morgan <morgan@...nel.org>, oleg@...ibm.com,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-api@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
	sgrubb@...hat.com
Subject: Re: [PATCH 3/3] p9auth: add p9auth driver

Quoting Eric Paris (eparis@...hat.com):
> On Wed, 2010-04-21 at 10:27 +0100, Alan Cox wrote:
> > > This is a change which must be discussed.  The use of this
> > > privilege can be completely prevented by having init remove
> > > CAP_GRANT_ID from its capability bounding set before forking any
> > > processes.
> > 
> > Which is a minor back compat issue - but you could start without it and
> > allow init to add it.
> > 
> > It seems a very complex interface to do a simple thing. A long time ago
> > there was discussion around extending the AF_UNIX fd passing to permit
> > 'pass handle and auth' so you could send someone a handle with a "become
> > me" token attached.
> 
> If you do go down this path there is a separate (and actually completely
> opposite) but related problem I might be able and willing to work with
> you on.  When looking at how auditing works in this modern day and age
> of dbus+polkit to get background processes to do work on behalf of a

This actually brings up an issue I've been a bit worried about: is
credentials passing for dbus adequate?  I thought that the last time
I looked through some code, there was no way in particular for upstart
to pass posix capabilities info along.  What that means is that as root
I can do

capsh --drop=(list of all capabilities) --
   reboot

and, although I don't have cap_sys_boot, I can reboot the system.  So
the only way I can prevent a container from rebooting the host is to
start it in a fresh network namespace to segrate the abstract unix
domain sockets.  But if I don't want a fresh network namespace, I'm out
of luck.

> user we were discussing an interface that would pass the information
> about the user to the background server process.  The background server
> process could do some magic such that it still had all the permissions
> and rights of itself, but had the audit information of the original
> user.  Thus even though it was a server process with uid=0 that did the
> work, the audit logs could know it was actually on behalf of uid=500.  
> 
> It was discussed passing that token of audit information over an AF_UNIX
> socket.
> 
> -Eric
--
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/