Thread (80 messages) 80 messages, 12 authors, 2024-08-09

Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)

From: Mickaël Salaün <mic@digikod.net>
Date: 2024-07-17 10:01:04
Also in: linux-fsdevel, linux-integrity, linux-security-module, lkml

On Wed, Jul 17, 2024 at 09:26:22AM +0100, Steve Dower wrote:
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).
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help