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: <1375384216.15733.210.camel@willson.li.ssimo.org>
Date:	Thu, 01 Aug 2013 15:10:16 -0400
From:	Simo Sorce <simo@...hat.com>
To:	Daniel Kahn Gillmor <dkg@...thhorseman.net>
Cc:	David Howells <dhowells@...hat.com>, keyrings@...ux-nfs.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Serge E. Hallyn" <serge.hallyn@...ntu.com>,
	linux-nfs@...r.kernel.org, krbdev@....edu,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] KEYS: Add per-user_namespace registers for
 persistent per-UID kerberos caches

On Thu, 2013-08-01 at 14:55 -0400, Daniel Kahn Gillmor wrote:
> On 08/01/2013 02:29 PM, Simo Sorce wrote:
> 
> > It's called 'abstraction' :-)
> 
> Good, I like abstraction :)
> 
> >> 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?
> > 
> > Just as a user can add data into a shm segment ?
> > Is there any difference ?
> 
> I guess this raises the question from a different perspective: if the
> kernel already supports arbitrary shm segments, filesystem locations,
> etc, which can be used for storing/passing opaque bytestrings between
> different parts of userspace, what advantages do we gain from having
> this new specific mechanism in the kernel?  Why couldn't those parts of
> userspace just rely on already-existing mechanisms instead of
> introducing this new interface?
> 
> Again, i'm not trying to say it's a bad idea; there's probably a
> big-picture piece of the puzzle that i don't see that makes this all
> obvious.  i just want to understand what it is.  Thanks for your
> explanations!

A few things deal with creation of the keyring and access control,
automatic garbage collection and in future the fact this data will not
leak in an intelligible form to disc (once we add the encryption bit to
the big_key type). Avoidance of naming collision and so on.
There is probably something else I am forgetting now.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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