Thread (3 messages) flat view 3 messages, 3 authors, 2021-12-01

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

From: Mimi Zohar <zohar@linux.ibm.com>
Date: 2021-12-01 13:18:31
Also in: linux-api, linux-fsdevel, linux-integrity, lkml

On Wed, 2021-12-01 at 10:23 +0100, Mickaël Salaün wrote:
On 30/11/2021 21:27, Florian Weimer wrote:
quoted
* Mickaël Salaün:
quoted
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.
The fact that IMA doesn't cover all metadata, file names nor the file 
hierarchies is well known and the solution can be implemented with 
dm-verity (which has its own drawbacks).
Thanks, Mickaël, for responding.  I'll go even farther and say that IMA
wasn't ever meant to protect file metadata.  Another option is EVM,
which addresses some, but not all of the issues.

thanks,

Mimi
trusted_for is a tool for interpreters to enforce a security policy 
centralized by the kernel. The kind of file confusion attacks you are 
talking about should be addressed by a system policy. If the mount point 
options are not enough to express such policy, then we need to rely on 
IMA, SELinux or IPE to reduce the scope of legitimate mapping between 
scripts and interpreters.
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help