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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux