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: <CAHk-=wjPGNLyzeBMWdQu+kUdQLHQugznwY7CvWjmvNW47D5sog@mail.gmail.com>
Date:   Tue, 5 Apr 2022 09:17:44 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Mickaël Salaün <mic@...ikod.net>
Cc:     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>,
        "Theodore Ts'o" <tytso@....edu>
Subject: Re: [GIT PULL] Add trusted_for(2) (was O_MAYEXEC)

On Tue, Apr 5, 2022 at 9:08 AM Mickaël Salaün <mic@...ikod.net> wrote:
>
> I think we don't. I think the only corner case that could be different
> is for files that are executable, SUID and non-readable. In this case it
> wouldn't matter because userspace could not read the file, which is
> required for interpretation/execution. Anyway, S[GU]ID bits in scripts
> are just ignored by execve and we want to follow the same semantic.

So I just want to bring up the possibility that somebody wants to just
implement execve() in user space for some reason - not just "script
interpreter".

It's *doable*.

Don't ask me if it's sane or useful, but people have done insane
things before. Things like "emulate other operating systems in user
space" etc

Such a user can trivially see the suid/sgid bit on the file (just do
fstat() on it), but wouldn't necessarily see if that file is then in a
mount that is mounted nosuid.

Now, I think the right thing to do is to just say "we don't support
it", but I do think it should perhaps be mentioned somewhere
explicitly.

Particularly since I can well imagine that a security policy might
have some "no, I don't allow suid exec" and return an actual error for
it, and then the access() call would fail for that case.

(Ok, so the security policies would look at the actual bprm data on a
real exec, not the inode executable, so that's kind of made up and
theoretical, but I just want this issue to be mentioned somewhere so
that people are aware that the "it's the same basic file checking that
execve does, but a _real_ execve might then have _other_ issues going
on, including suid bits etc")

               Linus