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:   Mon, 4 Apr 2022 16:26:44 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Mickaël Salaün <mic@...ikod.net>,
        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 4, 2022 at 3:25 PM Kees Cook <keescook@...omium.org> wrote:
>
> Maybe. I defer to Mickaël here, but my instinct is to avoid creating an
> API that can be accidentally misused. I'd like this to be fd-only based,
> since that removes path name races. (e.g. trusted_for() required an fd.)

Some people want pathnames. Think things like just the PATH thing just
to find the right executable in the first place.

For things like that, races don't matter, because you're just trying
to find the right path to begin with.

> I think this already exists as AT_EACCESS? It was added with
> faccessat2() itself, if I'm reading the history correctly.

Yeah, I noticed myself, I just hadn't looked (and I don't do enough
user-space programming to be aware of if that way).

> >     (a) "what about suid bits that user space cannot react to"
>
> What do you mean here? Do you mean setid bits on the file itself?

Right.

Maybe we don't care.

Maybe we do.

Is the user-space loader going to honor them? Is it going to ignore
them? I don't know. And it actually interacts with things like
'nosuid', which the kernel does know about, and user space has a hard
time figuring out.

So if the point is "give me an interface so that I can do the same
thing a kernel execve() loader would do", then those sgid/suid bits
actually may be exactly the kind of thing that user space wants the
kernel to react to - should it ignore them, or should it do something
special when it sees that they are set?

I'm not saying that they *should* be something we care about. All I'm
saying is that I want that *discussion* to happen.

               Linus