[prev in list] [next in list] [prev in thread] [next in thread] 

List:       systemd-devel
Subject:    Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev
From:       Josh Triplett <josh () joshtriplett ! org>
Date:       2020-01-02 19:08:21
Message-ID: 20200102190820.GA14694 () localhost
[Download RAW message or body]

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.

- Josh Triplett
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[prev in list] [next in list] [prev in thread] [next in thread]