Re: fexecve

[David Holland <dholland-tech%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost