From: Alyssa Ross <hi@alyssa.is>
To: Demi Marie Obenour <demiobenour@gmail.com>, devel@spectrum-os.org
Cc: Yureka Lilian <yureka@cyberchaos.dev>
Subject: Re: [PATCH] Set restrictive mount options
Date: Thu, 11 Dec 2025 21:30:01 +0100 [thread overview]
Message-ID: <87cy4ksqwm.fsf@alyssa.is> (raw)
In-Reply-To: <67073f8a-f9c4-4f30-ab23-9309e6d6f585@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3456 bytes --]
Demi Marie Obenour <demiobenour@gmail.com> writes:
> On 12/11/25 07:48, Alyssa Ross wrote:
>> These are mostly copied from systemd, so should be pretty safe in
>> terms of compatibility.
>>
>> Signed-off-by: Alyssa Ross <hi@alyssa.is>
>> ---
>> host/initramfs/etc/fstab | 8 ++++----
>> host/initramfs/etc/init | 2 +-
>> host/rootfs/image/etc/fstab | 12 ++++++------
>> img/app/image/etc/fstab | 12 ++++++------
>> img/app/image/etc/mdev/virtiofs | 2 +-
>> img/app/image/etc/s6-rc/app/run | 4 ++--
>> img/app/scripts/start-virtiofsd.elb | 2 +-
>> vm/app/systemd-sysupdate/download-update | 2 +-
>> vm/sys/net/image/etc/fstab | 12 ++++++------
>> 9 files changed, 28 insertions(+), 28 deletions(-)
>>
>> diff --git a/host/initramfs/etc/fstab b/host/initramfs/etc/fstab
>> index 3dfb05ab..9f43a1a9 100644
>> --- a/host/initramfs/etc/fstab
>> +++ b/host/initramfs/etc/fstab
>> @@ -1,5 +1,5 @@
>> # SPDX-License-Identifier: CC0-1.0
>> -# SPDX-FileCopyrightText: 2021 Alyssa Ross <hi@alyssa.is>
>> -devtmpfs /dev devtmpfs defaults 0 0
>> -proc /proc proc defaults 0 0
>> -sysfs /sys sysfs defaults 0 0
>> +# SPDX-FileCopyrightText: 2021-2025 Alyssa Ross <hi@alyssa.is>
>> +devtmpfs /dev devtmpfs nosuid 0 0
>
> Should this also be noexec? I don't think anything has any business
> executing something out of devtmpfs.
>
>> +proc /proc proc nosuid,nodev,noexec 0 0
>> +sysfs /sys sysfs nosuid,nodev,noexec 0 0
>> diff --git a/host/initramfs/etc/init b/host/initramfs/etc/init
>> index 71948874..723d2e1b 100755
>> --- a/host/initramfs/etc/init
>> +++ b/host/initramfs/etc/init
>> @@ -42,7 +42,7 @@ if {
>>
>> background { rm /dev/rootfs /dev/verity }
>>
>> -if { mount /dev/mapper/root-verity /mnt/root }
>> +if { mount -o nosuid,nodev /dev/mapper/root-verity /mnt/root }
>> wait { $mdevd_pid }
>>
>> if { mount --move /proc /mnt/root/proc }
>> diff --git a/host/rootfs/image/etc/fstab b/host/rootfs/image/etc/fstab
>> index 6230d910..5c23a374 100644
>> --- a/host/rootfs/image/etc/fstab
>> +++ b/host/rootfs/image/etc/fstab
>> @@ -1,7 +1,7 @@
>> # SPDX-License-Identifier: CC0-1.0
>> -# SPDX-FileCopyrightText: 2020-2021 Alyssa Ross <hi@alyssa.is>
>> -proc /proc proc defaults 0 0
>> -devpts /dev/pts devpts gid=5,mode=620 0 0
>> -tmpfs /dev/shm tmpfs defaults 0 0
>> -sysfs /sys sysfs defaults 0 0
>> -tmpfs /tmp tmpfs defaults 0 0
>> +# SPDX-FileCopyrightText: 2020-2021, 2025 Alyssa Ross <hi@alyssa.is>
>> +proc /proc proc nosuid,nodev,noexec 0 0
>> +devpts /dev/pts devpts nosuid,noexec,gid=5,mode=620 0 0
>> +tmpfs /dev/shm tmpfs nosuid,nodev 0 0
>> +sysfs /sys sysfs nosuid,nodev,noexec 0 0
>> +tmpfs /tmp tmpfs nosuid,nodev 0 0
>
> Should this be noexec as well?
Here's systemd's rationale for /dev and /tmp not to be noexec:
https://github.com/systemd/systemd/commit/4eb105fa4aae30566d23382e8c9430eddf1a3dd4
We could decide to be stricter, though.
For /tmp and maybe /dev/shm as well I'm tempted to leave them unmounted
and read-only by default, and only mount them inside namespaces for
particular services that need them. That way we'd know which services
were using them, and could decide on restrictive mount flags
per-service, as well as deciding whether /tmp should be RAM- or
disk-backed for each service.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2025-12-11 20:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-11 12:48 [PATCH] Set restrictive mount options Alyssa Ross
2025-12-11 18:07 ` Demi Marie Obenour
2025-12-11 19:04 ` Alyssa Ross
2025-12-11 20:30 ` Alyssa Ross [this message]
2025-12-11 19:24 ` Alyssa Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cy4ksqwm.fsf@alyssa.is \
--to=hi@alyssa.is \
--cc=demiobenour@gmail.com \
--cc=devel@spectrum-os.org \
--cc=yureka@cyberchaos.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).