linux-kernel - Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request

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] [day] [month] [year] [list]

Date:   Fri, 02 Jun 2017 17:34:14 +0100
From:   David Howells <dhowells@...hat.com>
To:     Colin Walters <walters@...bum.org>
Cc:     dhowells@...hat.com, James.Bottomley@...senPartnership.com,
        ebiederm@...ssion.com, linux-nfs@...r.kernel.org,
        containers@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org, keyrings@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, cgroups@...r.kernel.org
Subject: Re: [RFC PATCH] KEYS: Allow a live daemon in a namespace to service request_key upcalls

Colin Walters <walters@...bum.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