On 2.1.2020 21.08, Josh Triplett wrote:
Lennart Poettering wrote:
And noexec doesn't really make much sense for these dirs, as this
blocks mmap() with MAP_EXEC and there are plenty apps that want to use
that. Moreover "noexec" is at best a protection against accidental
execution and not a security mechanism since it is trivially easy to
circumvent (just call the interpreter directly with the file to
execute as first arg, which for ELF means "/lib64/ld-linux-x86-64.so.2 $BINARY")
That workaround doesn't actually work anymore; the former (blocking mmap
with MAP_EXEC) exists specifically to protect against the latter
(running the interpreter directly).
$ mount | grep '/run '
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1620848k,mode=755)
$ sudo cp -a /bin/ls /run/ls
$ /run/ls
bash: /run/ls: Permission denied
(126) $ /lib64/ld-linux-x86-64.so.2 /run/ls
/run/ls: error while loading shared libraries: /run/ls: failed to map segment from shared object
(127) $
It's theoretically possible to work around *that* if you have permission
to run arbitrary code and to remap memory from write to execute (both of
which might also be locked down). But even without that, mount -o noexec
does meaningfully improve security, and the trivial workaround no longer
works.
It's not theoretical at all. You can use memfd_create() to prepare a
file without it ever going to disk and then use
mmap(,,PROT_EXEC|PROT_READ,,) to put it into address space for execution.
Seccomp can be used to block memfd_create() but then some programs want
to use it, so it can't be blocked globally. SELinux PROCESS__EXECMEM
check may also be able to stop this, I haven't tried.
But then many interpreters (designed as such or accidentally
Turing-complete decoders) can also be used to go around all these file
system level checks.
-Topi
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
