linux-kernel - Re: [PATCH v14 0/3] Add trusted_for(2) (was O

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]

Message-Id: <20211011140755.a09af989de3ca844577d1ded@linux-foundation.org>
Date:   Mon, 11 Oct 2021 14:07:55 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Mickaël Salaün <mic@...ikod.net>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        Aleksa Sarai <cyphar@...har.com>,
        Andy Lutomirski <luto@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Casey Schaufler <casey@...aufler-ca.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Christian Heimes <christian@...hon.org>,
        Deven Bowers <deven.desai@...ux.microsoft.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Eric Biggers <ebiggers@...nel.org>,
        Eric Chiang <ericchiang@...gle.com>,
        Florian Weimer <fweimer@...hat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        James Morris <jmorris@...ei.org>, Jan Kara <jack@...e.cz>,
        Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...omium.org>,
        Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        "Madhavan T . Venkataraman" <madvenka@...ux.microsoft.com>,
        Matthew Garrett <mjg59@...gle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Miklos Szeredi <mszeredi@...hat.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Paul Moore <paul@...l-moore.com>,
        Philippe Trébuchet 
        <philippe.trebuchet@....gouv.fr>,
        Scott Shell <scottsh@...rosoft.com>,
        Shuah Khan <shuah@...nel.org>,
        Steve Dower <steve.dower@...hon.org>,
        Steve Grubb <sgrubb@...hat.com>,
        Thibaut Sautereau <thibaut.sautereau@....gouv.fr>,
        Vincent Strubel <vincent.strubel@....gouv.fr>,
        kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH v14 0/3] Add trusted_for(2) (was O_MAYEXEC)

On Mon, 11 Oct 2021 10:47:04 +0200 Mickaël Salaün <mic@...ikod.net> wrote:

> 
> On 10/10/2021 23:48, Andrew Morton wrote:
> > On Fri,  8 Oct 2021 12:48:37 +0200 Mickaël Salaün <mic@...ikod.net> wrote:
> > 
> >> The final goal of this patch series is to enable the kernel to be a
> >> global policy manager by entrusting processes with access control at
> >> their level.  To reach this goal, two complementary parts are required:
> >> * user space needs to be able to know if it can trust some file
> >>   descriptor content for a specific usage;
> >> * and the kernel needs to make available some part of the policy
> >>   configured by the system administrator.
> > 
> > Apologies if I missed this...
> > 
> > It would be nice to see a description of the proposed syscall interface
> > in these changelogs!  Then a few questions I have will be answered...
> 
> I described this syscall and it's semantic in the first patch in
> Documentation/admin-guide/sysctl/fs.rst

Well, kinda.  It didn't explain why the `usage' and `flags' arguments
exist and what are the plans for them.

> Do you want me to copy-paste this content in the cover letter?

That would be best please.  It's basically the most important thing
when reviewing the implementation.

> > 
> > long trusted_for(const int fd,
> > 		 const enum trusted_for_usage usage,
> > 		 const u32 flags)
> > 
> > - `usage' must be equal to TRUSTED_FOR_EXECUTION, so why does it
> >   exist?  Some future modes are planned?  Please expand on this.
> 
> Indeed, the current use case is to check if the kernel would allow
> execution of a file. But as Florian pointed out, we may want to add more
> context in the future, e.g. to enforce signature verification, to check
> if this is a legitimate (system) library, to check if the file is
> allowed to be used as (trusted) configuration…
> 
> > 
> > - `flags' is unused (must be zero).  So why does it exist?  What are
> >   the plans here?
> 
> This is mostly to follow syscall good practices for extensibility. It
> could be used in combination with the usage argument (which defines the
> user space semantic), e.g. to check for extra properties such as
> cryptographic or integrity requirements, origin of the file…
> 
> > 
> > - what values does the syscall return and what do they mean?
> > 
> 
> It returns 0 on success, or -EACCES if the kernel policy denies the
> specified usage.

And please document all of this in the changelog also.