Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Nov 2021 21:27:15 +0100
From: Florian Weimer <>
To: Mickaël Salaün <>
Cc: Al Viro <>,  Andrew Morton
 <>,  Alejandro Colomar <>,
  Aleksa Sarai <>,  Andy Lutomirski <>,
  Arnd Bergmann <>,  Casey Schaufler <>,
  Christian Brauner <>,  Christian Heimes
 <>,  Deven Bowers <>,
  Dmitry Vyukov <>,  Eric Biggers <>,
  Eric Chiang <>,  Geert Uytterhoeven
 <>,  James Morris <>,  Jan Kara
 <>,  Jann Horn <>,  Jonathan Corbet
 <>,  Kees Cook <>,  Lakshmi
 Ramasubramanian <>,  "Madhavan T . Venkataraman"
 <>,  Matthew Garrett <>,
  Matthew Wilcox <>,  Miklos Szeredi
 <>,  Mimi Zohar <>,  Paul Moore
 <>,  Philippe Trébuchet
 <>,  Scott Shell <>,
  Shuah Khan <>,  Steve Dower <>,
  Steve Grubb <>,  Thibaut Sautereau
 <>,  Vincent Strubel
 <>,  Yin Fengwei <>,,,,,,
Subject: 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

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).

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


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.