Re: [PATCH v17 0/3] Add trusted_for(2) (was O_MAYEXEC)

* Mickaël Salaün:

Primary goal of trusted_for(2)
==============================

This new syscall enables user space to ask the kernel: is this file
descriptor's content trusted to be used for this purpose?  The set of
usage currently only contains execution, but other may follow (e.g.
configuration, sensitive data).  If the kernel identifies the file
descriptor as trustworthy for this usage, user space should then take
this information into account.  The "execution" usage means that the
content of the file descriptor is trusted according to the system policy
to be executed by user space, which means that it interprets the content
or (try to) maps it as executable memory.

I sketched my ideas about “IMA gadgets” here:

  IMA gadgets
  <https://www.openwall.com/lists/oss-security/2021/11/30/1>

I still don't think the proposed trusted_for interface is sufficient.
The example I gave is a Perl module that does nothing (on its own) when
loaded as a Perl module (although you probably don't want to sign it
anyway, given what it implements), but triggers an unwanted action when
sourced (using .) as a shell script.

@usage identifies the user space usage intended for @fd: only
TRUSTED_FOR_EXECUTION for now, but trusted_for_usage could be extended
to identify other usages (e.g. configuration, sensitive data).

We would need TRUSTED_FOR_EXECUTION_BY_BASH,
TRUSTED_FOR_EXECUTION_BY_PERL, etc.  I'm not sure that actually works.

Caller process context does not work because we have this confusion
internally between glibc's own use (for the dynamic linker
configuration), and for loading programs/shared objects (there seems to
be a corner case where you can execute arbitrary code even without
executable mappings in the ELF object), and the script interpreter
itself (the primary target for trusted_for).

But for generating auditing events, trusted_for seems is probably quite
helpful.

Thanks,
Florian