[systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev

[Topi Miettinen]

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