lkml.org 
[lkml]   [2022]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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).

[...]

\
 
 \ /
  Last update: 2022-04-06 01:34    [W:0.149 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site