On Thu, Jul 18, 2024 at 5:23 AM Mickaël Salaün [off-list ref] wrote:

On Wed, Jul 17, 2024 at 06:51:11PM -0700, Jeff Xu wrote:

quoted

On Wed, Jul 17, 2024 at 3:00 AM Mickaël Salaün [off-list ref] wrote:

quoted

On Wed, Jul 17, 2024 at 09:26:22AM +0100, Steve Dower wrote:

quoted

On 17/07/2024 07:33, Jeff Xu wrote:

quoted

Consider those cases: I think:
a> relying purely on userspace for enforcement does't seem to be
effective,  e.g. it is trivial  to call open(), then mmap() it into
executable memory.

If there's a way to do this without running executable code that had to pass
a previous execveat() check, then yeah, it's not effective (e.g. a Python
interpreter that *doesn't* enforce execveat() is a trivial way to do it).

Once arbitrary code is running, all bets are off. So long as all arbitrary
code is being checked itself, it's allowed to do things that would bypass
later checks (and it's up to whoever audited it in the first place to
prevent this by not giving it the special mark that allows it to pass the
check).

We will want to define what is considered as "arbitrary code is running"

Using an example of ROP, attackers change the return address in stack,
e.g. direct the execution flow to a gauge to call "ld.so /tmp/a.out",
do you consider "arbitrary code is running" when stack is overwritten
? or after execve() is called.

Yes, ROP is arbitrary code execution (which can be mitigated with CFI).
ROP could be enough to interpret custom commands and create a small
interpreter/VM.

quoted

If it is later, this patch can prevent "ld.so /tmp/a.out".

quoted

Exactly.  As explained in the patches, one crucial prerequisite is that
the executable code is trusted, and the system must provide integrity
guarantees.  We cannot do anything without that.  This patches series is
a building block to fix a blind spot on Linux systems to be able to
fully control executability.

Even trusted executable can have a bug.

Definitely, but this patch series is dedicated to script execution
control.

quoted

I'm thinking in the context of ChromeOS, where all its system services
are from trusted partitions, and legit code won't load .so from a
non-exec mount.  But we want to sandbox those services, so even under
some kind of ROP attack, the service still won't be able to load .so
from /tmp. Of course, if an attacker can already write arbitrary
length of data into the stack, it is probably already a game over.

OK, you want to tie executable file permission to mmap.  That makes
sense if you have a consistent execution model.  This can be enforced by
LSMs.  Contrary to script interpretation which is a full user space
implementation (and then controlled by user space), mmap restrictions
should indeed be enforced by the kernel.

Ya, that is what I meant. it can be out of scope for this patch.
Indeed, as you point out, this patch is dedicated to script execution
control, and fixing ld.so /tmp/a.out is an extra bonus in addition to
script.

Thanks
-Jeff