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]

Date:	Wed, 21 Apr 2010 08:39:17 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	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 Paris <eparis@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-api@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>
Subject: Re: [PATCH 3/3] p9auth: add p9auth driver

Quoting Alan Cox (alan@...rguk.ukuu.org.uk):
> > 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.
> 
> Alan

Hi Alan,

sorry I thought I had cc:d you, bc I was pretty sure you'd have some
neat ideas.  Like this one.

One could try to argue that this makes every linux process susceptible
to a trojan making it grant its userid to other tasks, but of course
that's silly since the trojan could just fork.  Well, what this would
buy the attacker is the ability to sit inconspicuously under his old
userid, holding on to the fd until the admin goes out to coffee before
switching userids.

The other thing is that offhand I think the server can't easily tell
from the socket which user namespace the client is in, as ucred only
has .uid.  Though (1) we might need to create a 'struct puser' analogous
to 'struct pid' for signals anyway, (2) userspace can segragate with
fs or net_ns (if abstract sock), and (3) client in a container
presumably won't be able to authenticate itself to server on the
host anyway.

Ashwin (and Ron), I think this idea will give us the same tools that
the p9auth driver does, perhaps in a more unix-y way.  Would you have
objections, or do you see shortcomings?

Thanks, Alan.

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