Re: [PATCH 1/2] KEYS: Implement a big key type that can save to tmpfs

[Nico Williams]

On Thu, Aug 8, 2013 at 9:46 AM, David Howells <dhowells@xxxxxxxxxx> wrote:
> Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
>
>> b) how to create tmpfs locations in which to store credentials (which
>> can be unbounded in size, so storing them in the kernel is silly;
>
> Ummm...  tmpfs stores them in the kernel too - though it can page them out to
> swap.

Any filesystem uses kernel, doesn't it?  Notionally, however, they
don't.  And notionally tmpfs is not about using memory but about being
non-persistent.  This is important because tmpfs *is* subject to
swapping and that does create security problems (you should want to
encrypt swap).

There's a difference between "notionally not persistent across
reboots" and "notionally stored in the kernel's address space".  The
real question is: why do you want the latter?

Some people have argued (not in this thread, and not recently on this
list) that credentials should be stored in the kernel and not leave it
(i.e., you shouldn't be able to extract them from the kernel).  This
implies a number of things, but one of those is a bad thing: unbounded
kernel credential caches OR LRU/LFU cache eviction.  Some of us rely
on caching to keep latency predictable, so cache eviction could be a
bit rough.  Unbounded kernel credential caches not subject to paging
are a DoS.  Unbounded-but-paged cred caches would be fine, but really,
what's the difference vis-a-vis FILE ccaches in /tmp?  The answer
depends on whether you allow the creds to leave kernel space.

That brings us to: what do we really want?  If we really want users to
not be able to see their tickets' session keys, then we don't need to
store their tickets in kernel land and we don't need to put
krb5_mk_req*() in the kernel either: we need only *wrap* the keys to
that low-level crypto use of those keys happens in the kernel and the
only thing the kernel stores is the wrapping key.  You might even have
a TPM or similar crypto decelerator handle this.

ISTM that a new ccache type whose purpose is to defeat the tmpfs race
conditions of the FILE ccache is a good thing.  I would prefer it to
be *portable*, and it could be, but keyring stuff isn't.  And FILE
ccache remains the lowest common denominator, so there's that too.
And since I've been dealing with some FILE ccache race conditions (see
new thread I'll start next), I think a) I hate FILE ccaches, b) I
don't see how to avoid having them.

> I have altered my big-key implementation to just store small items in an
> internal buffer and big items in a tmpfs file.  This means that small items
> will use up _less_ kernel memory if they're in a key because they won't require
> the overhead of a dentry struct and an inode struct.

Please make sure to have a cache eviction policy...  I don't know what
is "small" when it comes to Kerberos credentials either.  If the
difference between small and large is "lacks / has PAC and/or CAMMAC"
then you'll find that this difference mostly depends on the
environment, and generally your items will be either all "small" or
all large.  Are you building dead code?

>> (b) can be solved in many ways, and the simplest is to have a
>> filesystem where top-level directories named after UIDs "exist" as
>> soon as they are referenced and as long as they are non-empty.  You
>> can use autofs + tmpfs, or a variant of tmpfs for this.
>
> Don't forget to add user namespaces into the mix :-/

Sure; why the ambivalence smiley?

Nico
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/