[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:       Mantas_Mikulėnas <grawity () gmail ! com>
Date:       2019-12-30 10:26:47
Message-ID: CAPWNY8XivgCnAoFv5MER4NNAK__Q3oQ7p9GHPRwDk2dp2U8n-g () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Mon, Dec 30, 2019 at 12:10 PM Patrick Schleizer <
patrick-mailinglists@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

[Attachment #5 (text/html)]

<div dir="ltr"><div dir="ltr">On Mon, Dec 30, 2019 at 12:10 PM Patrick Schleizer \
&lt;<a href="mailto:patrick-mailinglists@whonix.org">patrick-mailinglists@whonix.org</a>&gt; \
wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Hello,<br> <br>
a script to remount /home /tmp /dev/shm /run (configurable) with<br>
nosuid,nodev (+noexec configurable) has been created by me. The purpose<br>
of remounting is increasing the security of the system. The script shall<br>
run as early as reasonably possible during boot.<br>
<br>
The systemd unit file [1] and script [2] attached below in a simplified<br>
version or links to actual version. [3] [4] This is planned to be<br>
enabled by default in a Debian derivative Linux \
distribution.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>As for /home, that \
should just go into the fstab options (or a .mount.d drop-in).</div><div>  \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
The issue with the systemd unit file is that it runs the script while<br>
other scripts are run and it seems like &quot;mount -o nosuid,nodev --bind<br>
/tmp /tmp&quot; is non-atomic. By that I mean, other scripts (run by other<br>
systemd unit files) that require /tmp are experiencing a split second or<br>
so where /tmp is non-writeable and therefore fail. Various race<br>
condition are possible and one was already experienced.<br>
<br>
How to solve that?<br></blockquote><div><br></div><div>I&#39;m not sure why \
you&#39;re using --bind here. You can just change these options on an existing \
mountpoint using `-o remount`, as your own example script does.</div><div>  \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
Not using &#39;/etc/fstab.d&#39; because fstab &#39;.d&#39; folder does not exist \
yet.<br> [5] Not using &#39;/etc/fstab&#39; because that is non-ideal for a \
derivative<br> Debian Linux distribution. [6]<br></blockquote><div><br></div><div>All \
mounts exist as .mount units, so they can be overridden by custom .mount units and \
.mount.d/ drop-ins, similar to services.</div><div>  </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
a) The remount-secure.service unit file should run alone. Non-parallel.<br>
Until remount-secure.service is done, no other systemd unit files should<br>
be run. Is that possible with systemd?<br></blockquote><div><br></div><div>Have it \
run *before* systemd (i.e. do it from the initramfs). If I remember correctly, if the \
initramfs pre-mounts /run &amp;c. with the correct options, then systemd will just \
use that as-is and won&#39;t downgrade to the hardcoded options.</div><div>  \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
b) The remount-secure.service should add a reverse dependency to most<br>
other systemd unit files which is saying \
&quot;After=remount-secure.service&quot;.<br> Is that \
possible?<br></blockquote><div><br></div><div>Order your service before one of the \
early boot targets (such as sysinit). See the diagram in bootup(7).</div><div>  \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
c) Could the systemd unit file express &quot;do this right after systemd is<br>
done with the usual file system mounting but still? Which service or<br>
target would that be? &#39;Before=local-fs.target&#39; and<br>
&#39;After=systemd-remount-fs.service&#39;?<br>
<br>
d) Or remount-secure.service should not exist and instead be a drop-in<br>
configuration file snippet<br>
&#39;/lib/systemd/system/systemd-remount-fs.service.d/30_remount-secure.conf&#39;<br>
using &#39;ExecStartPost=/usr/lib/security-misc/remount-secure&#39;?<br></blockquote><div><br></div><div>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...</div><div><br></div></div>-- <br><div dir="ltr" \
class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>



_______________________________________________
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] 

Configure | About | News | Add a list | Sponsored by KoreLogic