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: <673bfc0f-7263-9404-3d88-6cc0ae1a1ae1@digikod.net>
Date:   Tue, 5 Apr 2022 17:55:58 +0200
From:   Mickaël Salaün <mic@...ikod.net>
To:     Kees Cook <keescook@...omium.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     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 05/04/2022 00:25, Kees Cook wrote:
> On Mon, Apr 04, 2022 at 02:28:19PM -0700, Linus Torvalds wrote:
>> Now, what I *think* you mean is
>>
>>   (1) user-space executable loaders want to be able to test the *same*
>> policy as the kernel does for execve()
> 
> Right. The script interpreter wants to ask "if this file were actually
> an ELF going through execve(), would the kernel allow it?"

The current behavior was a bit more flexible thanks to the sysctl. It 
was either the mount exec option check, the file perm check or both. The 
rationale is to let sysadmins adapt their system to existing 
applications/interpreters without breaking. Only basing the check on 
mount exec and file perm could be an issue in the short term, but I 
guess it would deter inconsistencies in existing systems… I'm not sure 
it is a wise move because if no interpreter want to use this check it 
would then be useless. See commit message in 
https://lore.kernel.org/all/20220104155024.48023-3-mic@digikod.net/ and 
the trusted_for_policy sysctl documentation:

"Even without enforced security policy, user space interpreters can use
this syscall to try as much as possible to enforce the system policy at
their level, knowing that it will not break anything on running systems
which do not care about this feature.  However, on systems which want
this feature enforced, there will be knowledgeable people (i.e. system
administrator who configured fs.trusted_for_policy deliberately) to
manage it. [...]"

> 
>>   (2) access(path, EXECVE_OK) will do the same permission checks as
>> "execve()" would do for that path
> 
> 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.)

The fd-based approach is definitely better from a security point of view 
but there is indeed a use case for pathnames. I guess we could highlight 
this point in the documentation.

> 
>>   (3) if you already have the fd open, use "faccess(fd, NULL,
>> F_OK_TO_EXECUTE, AT_EMPTY_PATH)"
> 
> Yes, specifically faccessat2(). (And continuing the race thought above,
> yes, there could still be races if the content of the file could be
> changed, but that case is less problematic under real-world conditions.)

I'm not worried about changes in the file once it is opened. This could 
be an issue but not in the kernel (e.g. flaky update system).

[...]