Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev
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
Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev
On Mo, 30.12.19 12:26, Mantas Mikulėnas (graw...@gmail.com) wrote: > > a script to remount /home /tmp /dev/shm /run (configurable) with > > nosuid,nodev (+noexec configurable) has been created by me. The purpose > > of remounting is increasing the security of the system. The script shall > > run as early as reasonably possible during boot. > > > > The systemd unit file [1] and script [2] attached below in a simplified > > version or links to actual version. [3] [4] This is planned to be > > enabled by default in a Debian derivative Linux distribution. > > > > On a standard Debian system, the three tmpfs mounts (/run, /tmp, /dev/shm) > *already have* the nosuid and nodev options – this is hardcoded in > mount-setup.c. So you should first figure out why they are not present in > your case to begin with. 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") I mean, we'd set it by default if it worked and if it would lock things down, but unfortunately it does neither really... > All mounts exist as .mount units, so they can be overridden by custom > .mount units and .mount.d/ drop-ins, similar to services. /run and /dev/shm are considered "API" mounts, i.e. systemd mounts them internally, and doesn't expose .mount units for them. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev
On Mon, Dec 30, 2019 at 12:10 PM Patrick Schleizer < patrick-mailingli...@whonix.org> wrote: > Hello, > > a script to remount /home /tmp /dev/shm /run (configurable) with > nosuid,nodev (+noexec configurable) has been created by me. The purpose > of remounting is increasing the security of the system. The script shall > run as early as reasonably possible during boot. > > The systemd unit file [1] and script [2] attached below in a simplified > version or links to actual version. [3] [4] This is planned to be > enabled by default in a Debian derivative Linux distribution. > On a standard Debian system, the three tmpfs mounts (/run, /tmp, /dev/shm) *already have* the nosuid and nodev options – this is hardcoded in mount-setup.c. So you should first figure out why they are not present in your case to begin with. As for /home, that should just go into the fstab options (or a .mount.d drop-in). > > The issue with the systemd unit file is that it runs the script while > other scripts are run and it seems like "mount -o nosuid,nodev --bind > /tmp /tmp" is non-atomic. By that I mean, other scripts (run by other > systemd unit files) that require /tmp are experiencing a split second or > so where /tmp is non-writeable and therefore fail. Various race > condition are possible and one was already experienced. > > How to solve that? > I'm not sure why you're using --bind here. You can just change these options on an existing mountpoint using `-o remount`, as your own example script does. > > Not using '/etc/fstab.d' because fstab '.d' folder does not exist yet. > [5] Not using '/etc/fstab' because that is non-ideal for a derivative > Debian Linux distribution. [6] > All mounts exist as .mount units, so they can be overridden by custom .mount units and .mount.d/ drop-ins, similar to services. > > a) The remount-secure.service unit file should run alone. Non-parallel. > Until remount-secure.service is done, no other systemd unit files should > be run. Is that possible with systemd? > Have it run *before* systemd (i.e. do it from the initramfs). If I remember correctly, if the initramfs pre-mounts /run &c. with the correct options, then systemd will just use that as-is and won't downgrade to the hardcoded options. > > b) The remount-secure.service should add a reverse dependency to most > other systemd unit files which is saying "After=remount-secure.service". > Is that possible? > Order your service before one of the early boot targets (such as sysinit). See the diagram in bootup(7). > > c) Could the systemd unit file express "do this right after systemd is > done with the usual file system mounting but still? Which service or > target would that be? 'Before=local-fs.target' and > 'After=systemd-remount-fs.service'? > > d) Or remount-secure.service should not exist and instead be a drop-in > configuration file snippet > '/lib/systemd/system/systemd-remount-fs.service.d/30_remount-secure.conf' > using 'ExecStartPost=/usr/lib/security-misc/remount-secure'? > Honestly I think this service should not exist, and instead be a static /etc/fstab or .mount unit configuration by the sysadmin, so that aill filesystems get the correct options from the beginning... -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev
Hello, a script to remount /home /tmp /dev/shm /run (configurable) with nosuid,nodev (+noexec configurable) has been created by me. The purpose of remounting is increasing the security of the system. The script shall run as early as reasonably possible during boot. The systemd unit file [1] and script [2] attached below in a simplified version or links to actual version. [3] [4] This is planned to be enabled by default in a Debian derivative Linux distribution. The issue with the systemd unit file is that it runs the script while other scripts are run and it seems like "mount -o nosuid,nodev --bind /tmp /tmp" is non-atomic. By that I mean, other scripts (run by other systemd unit files) that require /tmp are experiencing a split second or so where /tmp is non-writeable and therefore fail. Various race condition are possible and one was already experienced. How to solve that? Not using '/etc/fstab.d' because fstab '.d' folder does not exist yet. [5] Not using '/etc/fstab' because that is non-ideal for a derivative Debian Linux distribution. [6] a) The remount-secure.service unit file should run alone. Non-parallel. Until remount-secure.service is done, no other systemd unit files should be run. Is that possible with systemd? b) The remount-secure.service should add a reverse dependency to most other systemd unit files which is saying "After=remount-secure.service". Is that possible? c) Could the systemd unit file express "do this right after systemd is done with the usual file system mounting but still? Which service or target would that be? 'Before=local-fs.target' and 'After=systemd-remount-fs.service'? d) Or remount-secure.service should not exist and instead be a drop-in configuration file snippet '/lib/systemd/system/systemd-remount-fs.service.d/30_remount-secure.conf' using 'ExecStartPost=/usr/lib/security-misc/remount-secure'? e) Any other solution? Kind regards, Patrick [1] [Unit] Description=remount /home /tmp /dev/shm /run with nosuid,nodev (default) and noexec (opt-in) Documentation=https://github.com/Whonix/security-misc DefaultDependencies=no Before=sysinit.target Requires=local-fs.target After=local-fs.target After=qubes-sysinit.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/lib/security-misc/remount-secure [Install] WantedBy=sysinit.target [2] mount -o remount,nosuid,nodev /home mount -o remount,nosuid,nodev /run mount -o remount,nosuid,nodev /dev/shm mount -o nosuid,nodev --bind /tmp /tmp [3] https://github.com/Whonix/security-misc/blob/master/lib/systemd/system/remount-secure.service [4] https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/remount-secure [5] https://github.com/systemd/systemd/issues/12506 [6] Confusing question for users who upgrade or make changes to the file. (dpkg interactive conflict resolution dialog) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
