Bug 991110

Summary:	RFE: Add new kernel key type and per-UID persistent keyring for Kerberos support
Product:	Red Hat Enterprise Linux 7	Reporter:	Stephen Gallagher <sgallagh>
Component:	kernel	Assignee:	Herton R. Krzesinski <hkrzesin>
kernel sub component:	Key Management	QA Contact:	Red Hat Kernel QE team <kernel-qe>
Status:	CLOSED CURRENTRELEASE	Docs Contact:
Severity:	urgent
Priority:	high	CC:	andros, core-kernel-mgr, dhowells, dpal, ebenes, jhrozek, jlayton, mniranja, mzywusko, nalin, nc, pkis, qcai, rstrode, rwheeler, sgallagh, ssorce, walters
Version:	7.0	Keywords:	FutureFeature
Target Milestone:	beta
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	FailedQA
Fixed In Version:	kernel-3.10.0-44.el7	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-06-13 11:00:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	991148, 991169, 991184, 991185, 991186, 1005422, 1014739, 1029110

Description Stephen Gallagher 2013-08-01 16:44:37 UTC

Description of problem:
In order to address issues with file-based Kerberos credential caches, we should enhance the kernel keyring interface to support newer functionality. Based on discussions between Simo, Nalin, David and myself, we propose the following behavior:

1) We will add a new key type "big_key" that allows us to create keys up to 1MiB in size, backed by internal kernel tmpfs, allowing the contents to be swapped out to disk (unlike most other keyrings, which remain in unswappable kernel memory).

2) We will create a new public interface, keyctl_get_krbcache(uid_t, key_serial_t id). This API will allow the user (and certain privileged root processes such as rpc.gssd and gss-proxy) to access the keys for a particular UID. This keyring shall not be tied to a session (so it can outlive a user on the system if they need to perform actions while not logged in, such as access to secure NFS). The kernel keyring should be created automatically on the first request if it does not yet exist. It must also be possible to manipulate the lifetime timer with functions like keyctl_set_timeout() (to align the keyring life with the credential validity) and must also be possible to be destroyed immediately using the usual keyctl APIs (such as in the kdestroy case).


Version-Release number of selected component (if applicable):
keyutils-1.5.5-4.el7

Comment 2 Ray Strode [halfline] 2013-08-01 18:40:15 UTC

as part of 2), we really need some sort of change notification api as well so things like gnome-online-accounts can monitor the cache for changes.

Comment 5 Colin Walters 2013-09-06 15:08:30 UTC

What about something like "usertmpfs" which would polyinstantiate per uid?  Then userspace could mount it at /run/user.

What we avoid with this model is having to run the PAM stack just to have systemd mkdir("/run/user/X").  Instead, if a process with a given uid exists, that's enough to cause the directory to be auto-mounted effectively (if the process accesses the tmpdir).

Having "big" data in the kernel keyring is yet another place that userspace processes can accumulate data in a way not easily visible to administrators.

Notifications are just inotify, etc.

Comment 6 Nalin Dahyabhai 2013-09-10 16:10:26 UTC

In terms of merging strategy, which Fedora releases is this being targeted for?

Comment 7 Paul W. Frields 2013-09-10 21:52:49 UTC

Note, since RHEL 7.0 branched already and isn't automatically pulling from any Fedora releases any longer, needs to be merged with care.  (Sorry if this is obvious, not everyone reads the RHEL 7 schedule stuff.) ;-)

Comment 8 Stephen Gallagher 2013-09-12 13:41:05 UTC

@Nalin: If the Kernel team is willing to backport the new persistent keyring patches to F19, then we'll support F19. If not, it will be Fedora 20+

@Colin: We tried that approach, but we couldn't make it work with OpenSSH and a few other situations because they do the credential acquisition as a different user than the one that is logging in, so there's no guarantee that usertmpfs will have created the directory. There's also a race-condition inherent there.

Comment 10 David Howells 2013-10-02 16:25:50 UTC

The patches required for this are upstream as far as the linux-security tree and are awaiting the next merge window:

http://git.kernel.org/cgit/linux/kernel/git/jmorris/linux-security.git/commit/?h=next&id=ab3c3587f8cda9083209a61dbe3a4407d3cada10
http://git.kernel.org/cgit/linux/kernel/git/jmorris/linux-security.git/commit/?h=next&id=f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e

Comment 13 Ray Strode [halfline] 2013-11-04 17:17:21 UTC

Do the patches in the bug include a notification API? (re comment 2)

Comment 14 Dmitri Pal 2013-11-04 23:19:23 UTC

(In reply to Ray Strode [halfline] from comment #13)
> Do the patches in the bug include a notification API? (re comment 2)

I do not think so. All cred cache monitoring thing was deferred till later releases.

Comment 15 Dmitri Pal 2013-11-04 23:21:17 UTC

(In reply to Dmitri Pal from comment #14)
> (In reply to Ray Strode [halfline] from comment #13)
> > Do the patches in the bug include a notification API? (re comment 2)
> 
> I do not think so. All cred cache monitoring thing was deferred till later
> releases.

This means that the kerb notification app would continue to poll for ticket status. I should look at a different cache location/type though.

Have there been a bug about that? I thought there was.

Comment 16 Ray Strode [halfline] 2013-11-05 14:46:59 UTC

bug 991184 is the kerb notification app bug.  Is there a bug for the deferred kernel pieces?

Comment 18 Jarod Wilson 2013-11-06 14:58:53 UTC

Patch(es) available on kernel-3.10.0-42.el7

Comment 22 Jarod Wilson 2013-11-07 22:11:14 UTC

Patch(es) available on kernel-3.10.0-44.el7

Comment 30 Linqing Lu 2014-04-23 04:32:54 UTC

Verified with kernel-3.10.0-121 following comment 17:

$ keyctl get_persistent @p
425414281
$ keyctl get_persistent @p `id -u`
425414281
$ keyctl get_persistent @p 0
keyctl_get_persistent: Operation not permitted

# keyctl get_persistent @p
915649207
# keyctl get_persistent @p `id -u`
915649207
# keyctl get_persistent @p 0
915649207

Comment 31 Linqing Lu 2014-04-23 05:59:28 UTC

Verified same results on x86_64, ppc64 and s390x.

Comment 32 Ludek Smid 2014-06-13 11:00:23 UTC

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.