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]

Message-ID: <f93438e8-f568-a70d-2e03-4aa147932e00@digikod.net>
Date:   Tue, 5 Apr 2022 18:14:05 +0200
From:   Mickaël Salaün <mic@...ikod.net>
To:     Theodore Ts'o <tytso@....edu>
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 05/04/2022 16:54, Theodore Ts'o wrote:
> 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)

That would be an interesting syscall name. ;)


> 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.

Script execution is definitely the main use case and the semantic is 
already known by the kernel.


> 
> 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?

Thanks, I'll do some that.

> 
> Cheers,
> 
> 					- Ted