[RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Mickaël Salaün]

Hi,

This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC
series with a new syscall: introspect_access(2) .  Access check are now
only possible on a file descriptor, which enable to avoid possible race
conditions in user space.

For now, the only LSM hook triggered by introspect_access(2) is
inode_permission() which takes a struct inode as argument.  However,
struct path is still available in this syscall, which enables to add a
new hook to fit the needs of IMA and other path-based LSMs.

Goal of introspect_access(2)
============================

The goal of this patch series is to enable to control script execution
with interpreters help.  A new introspect_access() system call is added
to enable user space script interpreters to delegate to the kernel (and
thus the system security policy) the permission to interpret/execute
scripts or other files containing what can be seen as commands.

A simple system-wide security policy can be enforced by the system
administrator through a sysctl configuration consistent with the mount
points or the file access rights.  The documentation patch explains the
prerequisites.

Furthermore, the security policy can also be delegated to an LSM, either
a MAC system or an integrity system.  For instance, the new kernel
MAY_INTROSPECTION_EXEC flag is required to close a major IMA
measurement/appraisal interpreter integrity gap by bringing the ability
to check the use of scripts [1].  Other uses are expected, such as for
magic-links [2], SGX integration [3], bpffs [4] or IPE [5].

Possible extended usage
=======================

For now, only the X_OK mode is compatible with introspect_access(2).
This enables to restrict the addition of new control flows in a process.
Using R_OK or W_OK with introspect_access(2) returns -EINVAL.

Possible future use-cases for R_OK with introspect_access(2) may be to
check configuration files that may impact the behavior of applications
(i.e.  influence critical part of the current control flow).  Those
should then be trusted as well.  The W_OK with introspect_access(2)
could be used to check that a file descriptor is allowed to receive
sensitive data such as debug logs.

Prerequisite of its use
=======================

User space needs to adapt to take advantage of this new feature.  For
example, the PEP 578 [6] (Runtime Audit Hooks) enables Python 3.8 to be
extended with policy enforcement points related to code interpretation,
which can be used to align with the PowerShell audit features.
Additional Python security improvements (e.g. a limited interpreter
without -c, stdin piping of code) are on their way [7].

Examples
========

The initial idea comes from CLIP OS 4 and the original implementation
has been used for more than 12 years:
https://github.com/clipos-archive/clipos4_doc
Chrome OS has a similar approach:
https://chromium.googlesource.com/chromiumos/docs/+/master/security/noexec_shell_scripts.md

Userland patches can be found here:
https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC
Actually, there is more than the O_MAYEXEC changes (which matches this search)
e.g., to prevent Python interactive execution. There are patches for
Bash, Wine, Java (Icedtea), Busybox's ash, Perl and Python. There are
also some related patches which do not directly rely on O_MAYEXEC but
which restrict the use of browser plugins and extensions, which may be
seen as scripts too:
https://github.com/clipos-archive/clipos4_portage-overlay/tree/master/www-client

An introduction to O_MAYEXEC was given at the Linux Security Summit
Europe 2018 - Linux Kernel Security Contributions by ANSSI:
https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s
The "write xor execute" principle was explained at Kernel Recipes 2018 -
CLIP OS: a defense-in-depth OS:
https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s
See also an overview article: https://lwn.net/Articles/820000/

This patch series can be applied on top of v5.9-rc4 .  This can be tested
with CONFIG_SYSCTL.  I would really appreciate constructive comments on
this patch series.

Previous version:
https://lore.kernel.org/lkml/20200908075956.1069018-1-mic@digikod.net/

[1] https://lore.kernel.org/lkml/1544647356.4028.105.camel@linux.ibm.com/
[2] https://lore.kernel.org/lkml/20190904201933.10736-6-cyphar@cyphar.com/
[3] https://lore.kernel.org/lkml/CALCETrVovr8XNZSroey7pHF46O=kj_c5D9K8h=z2T_cNrpvMig@mail.gmail.com/
[4] https://lore.kernel.org/lkml/CALCETrVeZ0eufFXwfhtaG_j+AdvbzEWE0M3wjXMWVEO7pj+xkw@mail.gmail.com/
[5] https://lore.kernel.org/lkml/20200406221439.1469862-12-deven.desai@linux.microsoft.com/
[6] https://www.python.org/dev/peps/pep-0578/
[7] https://lore.kernel.org/lkml/0c70debd-e79e-d514-06c6-4cd1e021fa8b@python.org/

Regards,

Mickaël Salaün (3):
  fs: Add introspect_access(2) syscall implementation and related sysctl
  arch: Wire up introspect_access(2)
  selftest/interpreter: Add tests for introspect_access(2) policies

 Documentation/admin-guide/sysctl/fs.rst       |  50 +++
 arch/alpha/kernel/syscalls/syscall.tbl        |   1 +
 arch/arm/tools/syscall.tbl                    |   1 +
 arch/arm64/include/asm/unistd.h               |   2 +-
 arch/arm64/include/asm/unistd32.h             |   2 +
 arch/ia64/kernel/syscalls/syscall.tbl         |   1 +
 arch/m68k/kernel/syscalls/syscall.tbl         |   1 +
 arch/microblaze/kernel/syscalls/syscall.tbl   |   1 +
 arch/mips/kernel/syscalls/syscall_n32.tbl     |   1 +
 arch/mips/kernel/syscalls/syscall_n64.tbl     |   1 +
 arch/mips/kernel/syscalls/syscall_o32.tbl     |   1 +
 arch/parisc/kernel/syscalls/syscall.tbl       |   1 +
 arch/powerpc/kernel/syscalls/syscall.tbl      |   1 +
 arch/s390/kernel/syscalls/syscall.tbl         |   1 +
 arch/sh/kernel/syscalls/syscall.tbl           |   1 +
 arch/sparc/kernel/syscalls/syscall.tbl        |   1 +
 arch/x86/entry/syscalls/syscall_32.tbl        |   1 +
 arch/x86/entry/syscalls/syscall_64.tbl        |   1 +
 arch/xtensa/kernel/syscalls/syscall.tbl       |   1 +
 fs/open.c                                     |  79 ++++
 include/linux/fs.h                            |   3 +
 include/linux/syscalls.h                      |   1 +
 include/uapi/asm-generic/unistd.h             |   4 +-
 kernel/sysctl.c                               |  12 +-
 .../testing/selftests/interpreter/.gitignore  |   2 +
 tools/testing/selftests/interpreter/Makefile  |  18 +
 tools/testing/selftests/interpreter/config    |   1 +
 .../interpreter/introspection_policy_test.c   | 361 ++++++++++++++++++
 28 files changed, 547 insertions(+), 4 deletions(-)
 create mode 100644 tools/testing/selftests/interpreter/.gitignore
 create mode 100644 tools/testing/selftests/interpreter/Makefile
 create mode 100644 tools/testing/selftests/interpreter/config
 create mode 100644 tools/testing/selftests/interpreter/introspection_policy_test.c

-- 
2.28.0

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Matthew Wilcox]

On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote:
> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC
> series with a new syscall: introspect_access(2) .  Access check are now
> only possible on a file descriptor, which enable to avoid possible race
> conditions in user space.

But introspection is about examining _yourself_.  This isn't about
doing that.  It's about doing ... something ... to a script that you're
going to execute.  If the script were going to call the syscall, then
it might be introspection.  Or if the interpreter were measuring itself,
that would be introspection.  But neither of those would be useful things
to do, because an attacker could simply avoid doing them.

So, bad name.  What might be better?  sys_security_check()?
sys_measure()?  sys_verify_fd()?  I don't know.

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Mickaël Salaün]

On 10/09/2020 19:04, Matthew Wilcox wrote:
> On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote:
>> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC
>> series with a new syscall: introspect_access(2) .  Access check are now
>> only possible on a file descriptor, which enable to avoid possible race
>> conditions in user space.
> 
> But introspection is about examining _yourself_.  This isn't about
> doing that.  It's about doing ... something ... to a script that you're
> going to execute.  If the script were going to call the syscall, then
> it might be introspection.  Or if the interpreter were measuring itself,
> that would be introspection.  But neither of those would be useful things
> to do, because an attacker could simply avoid doing them.

Picking a good name other than "access" (or faccessat2) is not easy. The
idea with introspect_access() is for the calling task to ask the kernel
if this task should allows to do give access to a kernel resource which
is already available to this task. In this sense, we think that
introspection makes sense because it is the choice of the task to allow
or deny an access.

> 
> So, bad name.  What might be better?  sys_security_check()?
> sys_measure()?  sys_verify_fd()?  I don't know.
> 

"security_check" looks quite broad, "measure" doesn't make sense here,
"verify_fd" doesn't reflect that it is an access check. Yes, not easy,
but if this is the only concern we are on the good track. :)


Other ideas:
- interpret_access (mainly, but not only, for interpreters)
- indirect_access
- may_access
- faccessat3

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Mickaël Salaün]

On 10/09/2020 19:21, Mickaël Salaün wrote:
> 
> On 10/09/2020 19:04, Matthew Wilcox wrote:
>> On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote:
>>> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC
>>> series with a new syscall: introspect_access(2) .  Access check are now
>>> only possible on a file descriptor, which enable to avoid possible race
>>> conditions in user space.
>>
>> But introspection is about examining _yourself_.  This isn't about
>> doing that.  It's about doing ... something ... to a script that you're
>> going to execute.  If the script were going to call the syscall, then
>> it might be introspection.  Or if the interpreter were measuring itself,
>> that would be introspection.  But neither of those would be useful things
>> to do, because an attacker could simply avoid doing them.
> 
> Picking a good name other than "access" (or faccessat2) is not easy. The
> idea with introspect_access() is for the calling task to ask the kernel
> if this task should allows to do give access to a kernel resource which
> is already available to this task. In this sense, we think that
> introspection makes sense because it is the choice of the task to allow
> or deny an access.
> 
>>
>> So, bad name.  What might be better?  sys_security_check()?
>> sys_measure()?  sys_verify_fd()?  I don't know.
>>
> 
> "security_check" looks quite broad, "measure" doesn't make sense here,
> "verify_fd" doesn't reflect that it is an access check. Yes, not easy,
> but if this is the only concern we are on the good track. :)
> 
> 
> Other ideas:
> - interpret_access (mainly, but not only, for interpreters)
> - indirect_access
> - may_access
> - faccessat3
> 

I think that entrusted_access(2) looks good. What do you think?

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Mimi Zohar]

On Thu, 2020-09-10 at 19:21 +0200, Mickaël Salaün wrote:
> On 10/09/2020 19:04, Matthew Wilcox wrote:
> > On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote:
> >> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC
> >> series with a new syscall: introspect_access(2) .  Access check are now
> >> only possible on a file descriptor, which enable to avoid possible race
> >> conditions in user space.
> > 
> > But introspection is about examining _yourself_.  This isn't about
> > doing that.  It's about doing ... something ... to a script that you're
> > going to execute.  If the script were going to call the syscall, then
> > it might be introspection.  Or if the interpreter were measuring itself,
> > that would be introspection.  But neither of those would be useful things
> > to do, because an attacker could simply avoid doing them.
> 

Michael, is the confusion here that IMA isn't measuring anything, but
verifying the integrity of the file?   The usecase, from an IMA
perspective, is enforcing a system wide policy requiring everything
executed to be signed.  In this particular use case, the interpreter is
asking the kernel if the script is signed with a permitted key.  The
signature may be an IMA signature or an EVM portable and immutable
signature, based on policy.

> Picking a good name other than "access" (or faccessat2) is not easy. The
> idea with introspect_access() is for the calling task to ask the kernel
> if this task should allows to do give access to a kernel resource which
> is already available to this task. In this sense, we think that
> introspection makes sense because it is the choice of the task to allow
> or deny an access.
> 
> > 
> > So, bad name.  What might be better?  sys_security_check()?
> > sys_measure()?  sys_verify_fd()?  I don't know.
> > 
> 
> "security_check" looks quite broad, "measure" doesn't make sense here,
> "verify_fd" doesn't reflect that it is an access check. Yes, not easy,
> but if this is the only concern we are on the good track. :)

Maybe replacing the term "measure" with "integrity", but rather than
"integrity_check", something along the lines of fgetintegrity,
freadintegrity, fcheckintegrity.

Mimi

> 
> 
> Other ideas:
> - interpret_access (mainly, but not only, for interpreters)
> - indirect_access
> - may_access
> - faccessat3

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Mickaël Salaün]

On 10/09/2020 20:08, Mimi Zohar wrote:
> On Thu, 2020-09-10 at 19:21 +0200, Mickaël Salaün wrote:
>> On 10/09/2020 19:04, Matthew Wilcox wrote:
>>> On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote:
>>>> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC
>>>> series with a new syscall: introspect_access(2) .  Access check are now
>>>> only possible on a file descriptor, which enable to avoid possible race
>>>> conditions in user space.
>>>
>>> But introspection is about examining _yourself_.  This isn't about
>>> doing that.  It's about doing ... something ... to a script that you're
>>> going to execute.  If the script were going to call the syscall, then
>>> it might be introspection.  Or if the interpreter were measuring itself,
>>> that would be introspection.  But neither of those would be useful things
>>> to do, because an attacker could simply avoid doing them.
>>
> 
> Michael, is the confusion here that IMA isn't measuring anything, but
> verifying the integrity of the file?   The usecase, from an IMA
> perspective, is enforcing a system wide policy requiring everything
> executed to be signed.  In this particular use case, the interpreter is
> asking the kernel if the script is signed with a permitted key.  The
> signature may be an IMA signature or an EVM portable and immutable
> signature, based on policy.

There is also the use case of noexec mounts and file permissions. From
user space point of view, it doesn't matter which kernel component is in
charge of defining the policy. The syscall should then not be tied with
a verification/integrity/signature/appraisal vocabulary, but simply an
access control one.

> 
>> Picking a good name other than "access" (or faccessat2) is not easy. The
>> idea with introspect_access() is for the calling task to ask the kernel
>> if this task should allows to do give access to a kernel resource which
>> is already available to this task. In this sense, we think that
>> introspection makes sense because it is the choice of the task to allow
>> or deny an access.
>>
>>>
>>> So, bad name.  What might be better?  sys_security_check()?
>>> sys_measure()?  sys_verify_fd()?  I don't know.
>>>
>>
>> "security_check" looks quite broad, "measure" doesn't make sense here,
>> "verify_fd" doesn't reflect that it is an access check. Yes, not easy,
>> but if this is the only concern we are on the good track. :)
> 
> Maybe replacing the term "measure" with "integrity", but rather than
> "integrity_check", something along the lines of fgetintegrity,
> freadintegrity, fcheckintegrity.

What about entrusted_access(2)? It reflects the fact that the kernel
delegate to (trusted) user space tasks some access enforcements.

> 
> Mimi
> 
>>
>>
>> Other ideas:
>> - interpret_access (mainly, but not only, for interpreters)
>> - indirect_access
>> - may_access
>> - faccessat3
> 
> 

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Matthew Wilcox]

On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
> There is also the use case of noexec mounts and file permissions. From
> user space point of view, it doesn't matter which kernel component is in
> charge of defining the policy. The syscall should then not be tied with
> a verification/integrity/signature/appraisal vocabulary, but simply an
> access control one.

permission()?

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Al Viro]

On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote:
> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
> > There is also the use case of noexec mounts and file permissions. From
> > user space point of view, it doesn't matter which kernel component is in
> > charge of defining the policy. The syscall should then not be tied with
> > a verification/integrity/signature/appraisal vocabulary, but simply an
> > access control one.
> 
> permission()?

int lsm(int fd, const char *how, char *error, int size);

Seriously, this is "ask LSM to apply special policy to file"; let's
_not_ mess with flags, etc. for that; give it decent bandwidth
and since it's completely opaque for the rest of the kernel,
just a pass a string to be parsed by LSM as it sees fit.

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Matthew Wilcox]

On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote:
> On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote:
> > On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
> > > There is also the use case of noexec mounts and file permissions. From
> > > user space point of view, it doesn't matter which kernel component is in
> > > charge of defining the policy. The syscall should then not be tied with
> > > a verification/integrity/signature/appraisal vocabulary, but simply an
> > > access control one.
> > 
> > permission()?
> 
> int lsm(int fd, const char *how, char *error, int size);
> 
> Seriously, this is "ask LSM to apply special policy to file"; let's
> _not_ mess with flags, etc. for that; give it decent bandwidth
> and since it's completely opaque for the rest of the kernel,
> just a pass a string to be parsed by LSM as it sees fit.

Hang on, it does have some things which aren't BD^W^WLSM.  It lets
the interpreter honour the mount -o noexec option.  I presume it's
not easily defeated by
	cat /home/salaun/bin/bad.pl | perl -

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Mickaël Salaün]

On 10/09/2020 22:05, Matthew Wilcox wrote:
> On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote:
>> On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote:
>>> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
>>>> There is also the use case of noexec mounts and file permissions. From
>>>> user space point of view, it doesn't matter which kernel component is in
>>>> charge of defining the policy. The syscall should then not be tied with
>>>> a verification/integrity/signature/appraisal vocabulary, but simply an
>>>> access control one.
>>>
>>> permission()?
>>
>> int lsm(int fd, const char *how, char *error, int size);
>>
>> Seriously, this is "ask LSM to apply special policy to file"; let's
>> _not_ mess with flags, etc. for that; give it decent bandwidth
>> and since it's completely opaque for the rest of the kernel,
>> just a pass a string to be parsed by LSM as it sees fit.

Well, I don't know why you're so angry against LSM, but as noticed by
Matthew, the main focus of this patch series is not about LSM (no hook,
no security/* code, only file permission and mount option checks,
nothing fancy). Moreover, the syscall you're proposing doesn't make
sense, but I guess it's yet another sarcastic reply. Please, cool down.
We asked for constructive comments and already followed your previous
requests (even if we didn't get answers for some questions), but
seriously, this one is nonsense.

> 
> Hang on, it does have some things which aren't BD^W^WLSM.  It lets
> the interpreter honour the mount -o noexec option.  I presume it's
> not easily defeated by
> 	cat /home/salaun/bin/bad.pl | perl -
> 

Funny. I know there is a lot of text and links but please read the
commit messages before further comments.

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Igor Zhbanov]

On 10.09.2020 23:05, Matthew Wilcox wrote:
> On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote:
>> On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote:
>>> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
>>>> There is also the use case of noexec mounts and file permissions. From
>>>> user space point of view, it doesn't matter which kernel component is in
>>>> charge of defining the policy. The syscall should then not be tied with
>>>> a verification/integrity/signature/appraisal vocabulary, but simply an
>>>> access control one.
>>>
>>> permission()?
>>
>> int lsm(int fd, const char *how, char *error, int size);
>>
>> Seriously, this is "ask LSM to apply special policy to file"; let's
>> _not_ mess with flags, etc. for that; give it decent bandwidth
>> and since it's completely opaque for the rest of the kernel,
>> just a pass a string to be parsed by LSM as it sees fit.
> 
> Hang on, it does have some things which aren't BD^W^WLSM.  It lets
> the interpreter honour the mount -o noexec option.  I presume it's
> not easily defeated by
> 	cat /home/salaun/bin/bad.pl | perl -

Hi!

It could be bypassed this way. There are several ways of executing some
script:

1) /unsigned.sh (Already handled by IMA)
2) bash /unsigned.sh (Not handled. Works even with "-o noexec" mount)
3) bash < /unsigned.sh (Not handled. Works even with "-o noexec" mount)
4) cat /unsigned.sh | bash (Not handled. Works even with "-o noexec" mount)

AFAIK, the proposed syscall solves #2 and may be #3. As for #4 in security
critical environments there should be system-wide options to disable
interpreting scripts from the standard input. I suppose, executing commands
from the stdin is a rare case, and could be avoided entirely in security
critical environments. And yes, some help from the interpreters is needed
for that.

As for the usage of the system call, I have a proposal to extend its usage
to validate systemd unit files. Because a unit file could specify what UID
to use for a service, also it contains ExecStartPre which is actually a script
and is running as root (for the system session services).

For the syscall name it could be:
- trusted_file()
- trusted_file_content()
- valid_file()
- file_integrity()
because what we are checking here is the file content integrity (IMA) and
may be file permissions/attrs integrity (EVM).

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[James Morris]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On Thu, 10 Sep 2020, Matthew Wilcox wrote:

> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
> > There is also the use case of noexec mounts and file permissions. From
> > user space point of view, it doesn't matter which kernel component is in
> > charge of defining the policy. The syscall should then not be tied with
> > a verification/integrity/signature/appraisal vocabulary, but simply an
> > access control one.
> 
> permission()?
> 

The caller is not asking the kernel to grant permission, it's asking 
"SHOULD I access this file?"

The caller doesn't know, for example, if the script file it's about to 
execute has been signed, or if it's from a noexec mount. It's asking the 
kernel, which does know. (Note that this could also be extended to reading 
configuration files).

How about: should_faccessat ?

-- 
James Morris
<jmorris@namei.org>

Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)

[Mickaël Salaün]

Arnd and Michael,

What do you think of "should_faccessat" or "entrusted_faccessat" for
this new system call?


On 12/09/2020 02:28, James Morris wrote:
> On Thu, 10 Sep 2020, Matthew Wilcox wrote:
> 
>> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
>>> There is also the use case of noexec mounts and file permissions. From
>>> user space point of view, it doesn't matter which kernel component is in
>>> charge of defining the policy. The syscall should then not be tied with
>>> a verification/integrity/signature/appraisal vocabulary, but simply an
>>> access control one.
>>
>> permission()?
>>
> 
> The caller is not asking the kernel to grant permission, it's asking 
> "SHOULD I access this file?"
> 
> The caller doesn't know, for example, if the script file it's about to 
> execute has been signed, or if it's from a noexec mount. It's asking the 
> kernel, which does know. (Note that this could also be extended to reading 
> configuration files).
> 
> How about: should_faccessat ?
> 

Sounds good to me.

Re: [RFC PATCH v9 2/3] arch: Wire up introspect_access(2)

[Arnd Bergmann]

On Thu, Sep 10, 2020 at 6:46 PM Mickaël Salaün <mic@digikod.net> wrote:
>
> From: Mickaël Salaün <mic@linux.microsoft.com>
>
> Wire up access_interpreted(2) for all architectures.
>
> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
> Reviewed-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Vincent Strubel <vincent.strubel@ssi.gouv.fr>
> ---
>
> Changes since v7:
> * New patch for the new syscall.
> * Increase syscall numbers by 2 to leave space for new ones (in
>   linux-next): watch_mount(2) and process_madvise(2).

I checked that the syscall calling conventions are sane and that
it is wired up correctly on all architectures in this patch.

Acked-by: Arnd Bergmann <arnd@arndb.de>

I did not look at the system call implementation or its purpose though,
as that is not my area.