linux-kernel - Re: [GIT PULL] 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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 5 Apr 2022 10:54:22 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Mickaël Salaün <mic@...ikod.net>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Christian Heimes <christian@...hon.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        James Morris <jmorris@...ei.org>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Muhammad Usama Anjum <usama.anjum@...labora.com>,
        Paul Moore <paul@...l-moore.com>,
        Philippe Trébuchet 
        <philippe.trebuchet@....gouv.fr>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Steve Dower <steve.dower@...hon.org>,
        Thibaut Sautereau <thibaut.sautereau@....gouv.fr>,
        Vincent Strubel <vincent.strubel@....gouv.fr>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-integrity <linux-integrity@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        Christian Brauner <brauner@...nel.org>
Subject: Re: [GIT PULL] Add trusted_for(2) (was O_MAYEXEC)

On Mon, Apr 04, 2022 at 10:30:13PM +0200, Mickaël Salaün wrote:
> > If you add a new X_OK variant to access(), maybe that could fly.
> 
> As answered in private, that was the approach I took for one of the early
> versions but a dedicated syscall was requested by Al Viro:
> https://lore.kernel.org/r/2ed377c4-3500-3ddc-7181-a5bc114ddf94@digikod.net
> The main reason behind this request was that it doesn't have the exact same
> semantic as faccessat(2). The changes for this syscall are documented here:
> https://lore.kernel.org/all/20220104155024.48023-3-mic@digikod.net/
> The whole history is linked in the cover letter:
> https://lore.kernel.org/all/2ed377c4-3500-3ddc-7181-a5bc114ddf94@digikod.net/

As a suggestion, something that can be helpful for something which has
been as heavily bike-sheded as this concept might be to write a
"legislative history", or perhaps, a "bike shed history".

And not just with links to mailing list discussions, but a short
summary of why, for example, we moved from the open flag O_MAYEXEC to
the faccessat(2) approach.  I looked, but I couldn't find the
reasoning while diving into the mail archives.  And there was some
kind of request for some new functionality for IMA and other LSM's
that I couldn't follow that is why the new AT_INTERETED flag, but at
this point my time quantuum for mailing list archeology most
definitely expired.  :-)

It might be that when all of this is laid out, we can either revisit
prior design decisions as "that bike-shed request to support this
corner case was unreasonable", or "oh, OK, this is why we need as
fully general a solution as this".

Also, some of examples of potential future use cases such as "magic
links" that were linked in the cover letter, it's not clear to me
actually make sense in the context of a "trusted for" system call
(although might make more sense in the context of an open flag).  So
revisiting some of those other cases to see whether they actually
*could* be implemented as new "TRUSTED_FOR" flags might be
instructive.

Personally, I'm a bit skeptical about the prospct of additional use
cases, since trusted_for(2) is essentially a mother_should_I(2)
request where userspace is asking the kernel whether they should go
ahead and do some particular policy thing.  And it's not clear to me
how many of these policy questions exist where (a) the kernel is in
the past position to answer that question, and (b) there isn't some
additional information that the kernel doesn't have that might be
needed to answer that question.

For example, "Mother should I use that private key file" might require
information about whether the SRE is currently on pager duty or not,
at least for some policies, and the kernel isn't going to have that
information.

Other examples of TRUSTED_FOR flags that really make sense and would
be useful might help alleviate my skepticsm.  And the "bike shed
history" would help with my question about why some folks didn't like
the original O_MAYEXEC flag?

Cheers,

					- Ted