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

Steve Dower
2024-07-17T08:26:25Z

On 17/07/2024 07:33, Jeff Xu wrote:
> 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).

> b> if both user space and kernel need to call AT_CHECK, the faccessat
> seems to be a better place for AT_CHECK, e.g. kernel can call
> do_faccessat(AT_CHECK) and userspace can call faccessat(). This will
> avoid complicating the execveat() code path.
>
> What do you think ?
>
> Thanks
> -Jeff