On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote: > Here's a simple fexecve(2) implementation. Comments?
Two additional things come to mind besides the chroot issue: (1) For consistency of permission handling, it ought to require that the file be opened with O_EXEC, and check the execute bit at open time, not at exec time. However, I imagine that doing so is against whoever defined fexecve(). It also would create a gap in which a process could store up references to files that were previously executable and execute them later, perhaps after they've been modified. So that isn't unproblematic. But without that there are going to be a pile of odd corner cases, which I doubt we'll be able to identify in full beforehand, and some of which may turn out to be problematic as well. One that comes to mind is: if you open a program file for write while it's initially being written out, you can save that handle and use it later (after chmod) to both alter the program and execute it. On its own this isn't much use, but I'm not convinced that it can't be in combination with other circumstances. (2) Losing the command name isn't good; lots of people turn process accounting on for logging (in fact, I'd assume 99.9% of people who turn process accounting on use it purely for logging) and it substantially decreases the utility if it's easily circumvented. Also, breaking $ORIGIN for fexecve will probably lead to howling eventually. Not trivial to fix though. (3) Setugid processes should be prohibited, or at least setugid dynamically-linked processes, because otherwise there's a window where a live update of a library might be used to run the old binary with a new set of libraries. At least with ELF this can easily lead to UB that might be exploitable. -- David A. Holland [email protected]
