Re: systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 30, 2019 at 12:10 PM Patrick Schleizer <patrick-mailinglists@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux