Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls

From	David Howells <dhowells@redhat.com>
Newsgroups	linux.kernel
Subject	Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls
Date	2017-06-02 18:40 +0200
Message-ID	<tNXMd-3Dk-15@gated-at.bofh.it> (permalink)
References	<tNdT4-6EZ-11@gated-at.bofh.it> <tNckh-5yl-1@gated-at.bofh.it> <tMRSz-16W-25@gated-at.bofh.it> <tNd6G-67G-1@gated-at.bofh.it> <tNdT4-6EZ-11@gated-at.bofh.it>
Organization	Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903

Show all headers | View raw

Colin Walters <walters@verbum.org> wrote:

> Providing a feature without *known* users in a security-sensitive context
> seems to me to be something to think twice about.

Ummm...  Kernel DNS lookups, NFS idmapper upcalls.  CIFS could use it too.

> Kind of - what I'm getting at is that today, changing any of the kernel
> upcalls is a fully privileged operation.

Yes.  Upcalls are more secure but finding out the collection of namespaces in
which to run an upcall is a real pain - and Eric's 'concrete' method doesn't
actually work.

> (Wait, is /sbin/request-key really hardcoded in the kernel?  I guess that's
>  good from the perspective of not having containers be able to change it 
>  like they could /proc/sys/kernel/core_pattern if it was writable, but
>  it seems surprising)

Namespaces didn't exist at the time.

> Anyways, if we now expose a method to configure this, we have to look
> at the increase in attack surface.

To quote:

> In practice again, most container implementations I'm aware of use
> seccomp today to simply block off access to the keyring.

We're going to have to deal with that, but it's going to take some support on
the kernel side.  I think it may require a 'key' namespace - but that's going
to have potentially difficult interactions with the 'net' namespace for
network filesystems where your process's key and net namespaces are different
to the that of the superblock you're trying to access.

> > > Basically my instinct here is to be conservative and have
> > > KEYCTL_SERVICE_ADD require CAP_SYS_ADMIN and only affect the userns
> > > keyring.

Sorry, what 'userns' keyring?

> At a high level I'm glad you're looking at the "service fd" model instead of
> upcalls - I do think it'll get us to a better place.

I disagree, but it may be the only way, given the unholy mess in which the
Linux 'container' system works.

David

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[RFC PATCH] KEYS: Allow a live daemon in a namespace to service  request_key upcalls David Howells <dhowells@redhat.com> - 2017-05-30 18:10 +0200
  Example daemon program David Howells <dhowells@redhat.com> - 2017-05-30 18:20 +0200
  Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service  request_key upcalls Colin Walters <walters@verbum.org> - 2017-05-31 16:00 +0200
    Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls David Howells <dhowells@redhat.com> - 2017-05-31 16:50 +0200
      Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service  request_key upcalls Colin Walters <walters@verbum.org> - 2017-05-31 17:40 +0200
        Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service  request_key upcalls Jeff Layton <jlayton@redhat.com> - 2017-06-02 17:50 +0200
          Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls David Howells <dhowells@redhat.com> - 2017-06-02 18:20 +0200
        Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls David Howells <dhowells@redhat.com> - 2017-06-02 18:40 +0200

csiph-web