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: <20100421151917.5ae20265@lxorguk.ukuu.org.uk>
Date:	Wed, 21 Apr 2010 15:19:17 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	"Serge E. Hallyn" <serue@...ibm.com>
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

> 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.

Possibly, could you put a timestamp in the passed object ? (Given the
expiry of such a uid offer is kind of policy)

> 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.

That I think needs fixing anyway and now is a good time as any to do it.
If you are going to be able to pass userids then you need to be sure you
don't get passed a handle with a uid change on it that you didn't want so
adding another object type and option of some kind to accept them has to
occur anyway.

That also btw needs fixing for other reasons - more than one daemon has
been written that generically uses recvmsg and so can be attacked with FD
leaks >-)

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