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

Message-ID: <1856.1496420040@warthog.procyon.org.uk>
Date:   Fri, 02 Jun 2017 17:14:00 +0100
From:   David Howells <dhowells@...hat.com>
To:     Jeff Layton <jlayton@...hat.com>
Cc:     dhowells@...hat.com, Colin Walters <walters@...bum.org>,
        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

Jeff Layton <jlayton@...hat.com> wrote:

> Ideally we'd like to run the upcall in the same set of namespaces that
> the user process initiating the activity is running.

Unfortunately, that's not necessarily good enough.  A process could see, for
example, a mounted network fs that it can interact with that has a different
network namespace to the one in that the process is in.

This is an issue that the in-kernel AFS fs has a particular problem with
because there is a userspace management tool suite that uses AF_RXRPC sockets,
but calling socket() will open it in the calling process's namespace, not the
target filesystem's namespace.

I think we need some sort of pin that you can put in the namespace map that
says that for certain combinations of namespaces, you come to this pin and
service requests here, in the set of namespaces at this point.

David