* 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
On 30/11/2021 21:27, Florian Weimer wrote:
* 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).
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.
quoted
@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.
Well, this doesn't scale and that is the reason trusted_for usage is
more generic. The kernel already has all the information required to
identify scripts and interpreters types. We don't need to make the user
space interface more complex by listing all types. The kernel only miss
the semantic of how the intrepreter wants to interpret files, and that
is the purpose of trusted_for. LSMs are designed to define complex
policies and trusted_for enables them to extend such policies.
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).
The current use case for trusted_for is script interpreters, but we can
extend the trusted_for_usage enum with new usages like TRUSTED_FOR_LINK
and others. I'm not convinced glibc should be treated differently than
other executable code that want to load a shared library, but it is a
discussion we can have when trusted_for will be in mainline and someone
will propose a new usage. ;)
But for generating auditing events, trusted_for seems is probably quite
helpful.
Indeed, it enables to add semantic to audit events.
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.