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

Mantas Mikulėnas grawity at gmail.com
Mon Dec 30 10:26:47 UTC 2019


On Mon, Dec 30, 2019 at 12:10 PM Patrick Schleizer <
patrick-mailinglists at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20191230/d0346025/attachment.htm>


More information about the systemd-devel mailing list