linux-kernel - Re: [PATCH 2/2] KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches

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: <7370.1375463560@warthog.procyon.org.uk>
Date:	Fri, 02 Aug 2013 18:12:40 +0100
From:	David Howells <dhowells@...hat.com>
To:	Daniel Kahn Gillmor <dkg@...thhorseman.net>
Cc:	dhowells@...hat.com, keyrings@...ux-nfs.org,
	linux-nfs@...r.kernel.org, krbdev@....edu,
	"Serge E. Hallyn" <serge.hallyn@...ntu.com>,
	linux-kernel@...r.kernel.org, simo@...hat.com,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH 2/2] KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches

Daniel Kahn Gillmor <dkg@...thhorseman.net> wrote:

> > The uid is -1 or the user's own UID for the user's own cache or the uid of
> > some other user's cache (requires CAP_SETUID).  This permits rpc.gssd or
> > whatever to mess with the cache.
> 
> Is the goal here eventually to be able to avoid the upcall to rpc.gssd
> entirely?  It seems a little bit roundabout to have the kernel call up
> into userspace for the credentials, only to talk to a process which then
> calls back into the kernel for something that the kernel has already
> well-defined internally.

I would like to see use of request_key() eventually so that the kernel can
fish a key directly out of the keyring if it needs one.  My kAFS filesystem
could pretty much use that immediately.

However, I don't really want to put all the Kerberos communications into the
kernel.  The keys obtained by request_key() on behalf of a filesystem might be
kerberos tickets or they might be something else.

> It seems like a non-privileged user could use this to store arbitrary data
> in this keyring as a way of hiding what would otherwise be filesystem
> activity or using it for some sort of odd/sneaky IPC mechanism.  Is this an
> intentional side effect?

It is true that a non-privileged user can store arbitrary keys in their
keyring and they could use it as an IPC mechanism if they really wanted to -
but if they could do that, they could use socketpairs, pipes or shm instead so
I'm not sure they can do anything that they couldn't do by some other
mechanism anyway.

Note that key accesses are regulated by the active LSM and I think can appear
in the audit log.

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