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: <CA+EESO5kDbSCcpzxij6M0aWXqKDyFds+azksQFrXES6ACzTFtA@mail.gmail.com>
Date:   Mon, 17 Aug 2020 14:10:20 -0700
From:   Lokesh Gidra <lokeshgidra@...gle.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     James Morris <jmorris@...ei.org>,
        Stephen Smalley <stephen.smalley.work@...il.com>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Eric Biggers <ebiggers@...nel.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Paul Moore <paul@...l-moore.com>,
        Eric Paris <eparis@...isplace.org>,
        Daniel Colascione <dancol@...col.org>,
        Kees Cook <keescook@...omium.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        KP Singh <kpsingh@...gle.com>,
        David Howells <dhowells@...hat.com>,
        Thomas Cedeno <thomascedeno@...gle.com>,
        Anders Roxell <anders.roxell@...aro.org>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Matthew Garrett <matthewgarrett@...gle.com>,
        Aaron Goidel <acgoide@...ho.nsa.gov>,
        Randy Dunlap <rdunlap@...radead.org>,
        "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        YueHaibing <yuehaibing@...wei.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Adrian Reber <areber@...hat.com>,
        Aleksa Sarai <cyphar@...har.com>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        SElinux list <selinux@...r.kernel.org>,
        Kalesh Singh <kaleshsingh@...gle.com>,
        Calin Juravle <calin@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Nick Kralevich <nnk@...gle.com>,
        Jeffrey Vander Stoep <jeffv@...gle.com>,
        kernel-team@...roid.com, Daniel Colascione <dancol@...gle.com>
Subject: Re: [PATCH v6 1/3] Add a new LSM-supporting anonymous inode interface

On Fri, Aug 7, 2020 at 4:02 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Fri, Aug 07, 2020 at 03:49:39PM -0700, Lokesh Gidra wrote:
>
> > The new functions accept an optional context_inode parameter that
> > callers can use to provide additional contextual information to
> > security modules, e.g., indicating that one anonymous struct file is a
> > logical child of another, allowing a security model to propagate
> > security information from one to the other.
>
> What the hell is "logical child" and what are the lifetime rules implied
> by that relationship?

context_inode provides the security context required by the security
modules for granting/denying permission to create an anon inode of the
same type.

In case of userfaultfd, the relationship between the context_inode and
the created inode is described as that of ‘logical child’ because the
context_inode (userfaultfd inode of the parent process) provides the
security context required for creation of child process’ userfaultfd
inode. But there is no relationship beyond this point. Therefore, no
reference to context_inode is held anywhere.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ