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

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: <CAK3OfOj6E_thwgwdZUDXrr_7XW4xJkzwxdGU6gKcEJ3twOsm=A@mail.gmail.com>
Date:	Fri, 2 Aug 2013 15:49:06 -0500
From:	Nico Williams <nico@...ptonector.com>
To:	David Howells <dhowells@...hat.com>
Cc:	keyrings@...ux-nfs.org, linux-nfs@...r.kernel.org, simo@...hat.com,
	linux-kernel@...r.kernel.org, krbdev@....edu
Subject: Re: [PATCH 1/2] KEYS: Implement a big key type that can save to tmpfs

I think this is the wrong design.

There are two problems you're trying to solve:

a) how rpc.gssd finds credentials for processes on behalf of which it's acting

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; also
the apps that use them are all user-land apps, so that too means
there's no point in storing them in the kernel).

Keyrings for the forst problem (or PAGs, or anything similar) is fine:
on upcall to gssd the kernel tells it what it needs to know to find
those credentials.

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

Solving (b) in a way that does not add a new ccache type (though
having a KEYRING: ccache type that means "find the ccache URI in my
keyring" is fine) is important because many of us run multiple
implementations of Kerberos on any given host, and we do it because:

 - vendors are always behind the curve
 - legacy software linked with old versions of libkrb5 and friends
 - third party software

Please review the above.  Thanks,

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