(re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?

Development
,
41

Options=bind needed? See systemd mailing list. They were asking why use mount bind.

1 Like
42

Ok.

Seems like we’ll be stuck with initramfs-tools forever or at least until/if all major distributions (or at least Debian) switch to dracut by default.

About /run…

Older quote https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/:

  • The initrd should mount /run as a tmpfs and pass it pre-mounted when jumping into the main system when executing systemd. The mount options should be mode=755,nodev

Newer quote Initrd Interface

  • The initrd should mount /run/ as a tmpfs and pass it pre-mounted when jumping into the main system when executing systemd. The mount options should be mode=755,nodev,nosuid,strictatime .

This speaks for a initrd based implementation.

If stuck, could you please ask on systemd mailing list?

Also I guess it would be better to have only 1 place to implement mount options. Either do everything inside initramfs or do everything using systemd units. Not two places to implement. I.e. not initramfs + systemd units. Reason: lower complexity.

If going the systemd way, could you please make this configurable?
Due to high potential for regressions [1], we’ll ship this disabled by default and then call for testers enabling this.
Using systemd unit files it may be possible to implement this by requiring kernel boot parameter remount-secure being set by extending the [Unit] section of the systemd unit file. Example:

[Unit]
ConditionKernelCommandLine=|remount-secure

Type=ext4

Is this required? Or could be auto detected? Since you like to support non-Whonix, non-Kicksecure users (plain Debian) too, this might break when users are using other file systems such as btrfs.

Type=

Takes a string for the file system type. See mount(8) for details. This setting is optional.

Therefore I guess it can be dropped and would be auto detected by systemd if needed.

[Mount]
## Uncomment this to deny execution of programs in /home.
#Options=noexec

The problem with that is that this file will be replaced once a comment or something is ever changed there in the package. Would be better to add instructions there how to do that in /etc or glaceing that file in /etc perhaps. Or maybe better, instead we could probably use:

[Unit]
ConditionPathExists=|/etc/noexec
ConditionPathExists=|/usr/local/etc/noexec

(And/or /etc/exec / /usr/local/etc/exec.)

I.e. two systemd units. home-exec.mount and home-noexec.mount and which one is used/ignored depending on ConditionPathExists.

filename /lib/systemd/system/bin.mount

Must be /lib/systemd/system/bin.mount
Cannot be /lib/systemd/system/bin.mount.d?
Filename could also be /lib/systemd/system/remount-secure-bin.mount?

What about the mount options for the root file system / itself?

How to test if / is mounted with nodev?

[1] I previously had Qubes VMs which would boot sometimes, not boot at other times or sometimes would have broken AppArmor

1 Like
43

Bind mounts are needed because we aren’t using different partitions.

No, there isn’t a bin.mount in the first place so bin.mount.d won’t work.

No, systemd gives an error.

Mounting / with nodev would break all devices in /dev.

1 Like
44

Checking for /etc/remount-secure would be a better implementation:

ConditionPathExists=/etc/remount-secure

Won’t work:

home-noexec.mount: Where= setting doesn't match unit name. Refusing.
1 Like
45

In case you’re wondering why this is not merged yet…

1 Like
46

Quote Mount /rw and /home with nosuid + nodev ¡ Issue #5263 ¡ QubesOS/qubes-issues ¡ GitHub

nodev on /home breaks qubes-builder (specifically: /dev/null and probably other devices inside chroot). I wonder what else…

Probably also breaks Whonix build script which uses chroot in home and cowbuilder which uses chroot in /var.

1 Like
47

Quote Environment setup — CLIP OS 5.0.0_beta3 documentation

Make sure to work in a filesystem without any restricted features such as noexec or nodev as it will cause undefined issues throughout the building process of some parts of the CLIP OS images.

The rationale of nosuid in /home, /run, /dev/shm and /tmp (all partially user writable) is somewhat clear. Perhaps nosuid by extension too (lower attack surface).

But what’s the rationale of mounting /etc and some other folders with nodev? CLIP OS doesn’t do that. Out commented by their default. I haven’t seen /etc suggested to be mounted with nosuid, nodev anywhere.

Maybe the argument of principle of least privilege? Well, non-root users cannot write to these folders such as /etc by default anyhow. Only root can. And compromised root could also change mount options. Therefore I don’t see any advantage of mounting /etc with nosuid, nodev. Root can always create a lets say suid file in some folder (even /). The only way to prevent that would be untrusted root / appamor-profile-everything.

Maybe a useful question to ask…? Was there ever any vulnerability that would have been prevented by such mount options on such folders?

If not recommended anywhere / not helpful in any threat model, then better keep things minimal.

1 Like
48

Yes.

Root can leave unknown suid/devices lying around.

Not with apparmor-profile-everything.

Not that I know of but we should aim to be proactive i.e. using principle of least privilege to prevent potential future vulnerabilities rather than reactive i.e. responding to a known vulnerability.

There’s not really any legitimate reason of having devices/suid in /etc so why allow it at all?

49

Kurt Seifried - LASG / Installation recommends it

50

Brevity.

It’s good to be innovative. Such as in case of Whonix shipping kloak by default is a win. That threat model has been demonstrated through a proof of concept already. Proactive yes, but in this case of remounting /etc with nosuid the benefit of the change doesn’t have a strong rationale.

There’s a huge amount of things which won’t make sense from our point of view. For example there is the hello package which most users won’t know and won’t install. I am using it as an example here. No need to pick on that particular maintainer of that Debian package. Why allow installation of that package? What if that maintainer turned evil and somehow included a backdoor in the hello package? To prevent such a backdoor from doing damage, there could be an apt wrapper that prevents installation of that and other packages which most users will probably never need. I am not supposing to invent an apt wrapper for this hypothetical scenario. It would be worse having that code than having that risk.

The superior reason from preventing untrusted root writing anything malicious /etc is apparmor-profile-everything. Once that’s done, there is no need for an additional layer for preventive of suid creation in /etc. Many goals can be implemented in multiple ways but I don’t think we should implement every goal using duplicate implementations.

For example, remount-secure all inside initramfs (supposing that is possible) would be fine. Then that shouldn’t be fully duplicated with remount-secure again using systemd.

I cannot imagine any accident how any system administrator would create an suid binary and store it in /etc. And if a system administrator chooses for some reason to but a suid binary there then there’s no need to interfere with that choice.

It’s one valid strategy to optimize is to add safeguards for every cases no matter how likely. However, also Focus on low-effort maintainability is important which includes keeping the amount of lines of code small or even reducing it (i have some plans such as “tb-updater → binaries-freedom”…). By keeping the code size small it’s also more contributor friendly since more easy to understand, easier to review.

It’s in the table there but there’s no rationale for it either.

Keeping notes here now:

I not not sure if Mount /rw and /home with nosuid + nodev ¡ Issue #5263 ¡ QubesOS/qubes-issues ¡ GitHub is indicating that flatpak and snap also break when using nosuid on /home.

1 Like
51

I found a rationale for /etc mounted with nodev,nosuid as well as /var. This is because some folders in /etc or /var such as /var/www are owned by other users than root. In these cases the owner of these folders shouldn’t be able to create devices or suid binaries there.

1 Like
52
53

New approach:

  • delete security-misc /lib/systemd/system/remount-secure.service
  • move security-misc /usr/lib/security-misc/remount-secure to /etc/initramfs-tools/scripts/init-bottom/30_remount-secure

Details:

Script /usr/lib/security-misc/remount-secure was probably already good enough - the only missing part is moving it to initramfs to avoid race conditions.

initramfs also uses contents from folder /usr/share/initramfs-tools/scripts/init-bottom/ (and /usr/share/initramfs-tools/).

File name 30_ prepended because we want this to be run after /usr/share/initramfs-tools/scripts/init-bottom/udev.

Can probably stay a bash script. No need to port to sh. /usr/share/initramfs-tools/hooks/resume also uses bash.

if [ -e /etc/remount-disable ] || [ -e /usr/local/etc/remount-disable ]; then

Does this need ${rootmnt}? Likely not because at initramfs stage init-bottom, initramfs already moved everything to its final place?

Kernel parameter break=bottom might give a initramfs rescue shell which could be used for experimentation, i.e. manually running mount commands.

Might also be possible to add command bash followed to /etc/initramfs-tools/scripts/init-bottom/30_remount-secure to easily get shell for experimentation.

Adding sleep 10 or so during development to the end of the script might help to easily see what the script is doing, to have sufficient time to read its debug output.

Could you try please? @madaidan

1 Like
54

That doesn’t work. The mount options are only set when running update-initramfs. Nothing happens during boot.

1 Like
55

madaidan via Whonix Forum:

That doesn’t work. The mount options are only set when running update-initramfs. Nothing happens during boot.

Strange. Was it set to chmod +x?

Then how did you implement
/etc/initramfs-tools/scripts/init-bottom/sysctl-initramfs which is
kinda similar (as far as starts during initramfs)? Why would
sysctl-initramfs work but remote-secure not?

1 Like
56

Yes.

Dunno. sysctl-initramfs is just writing to a few files. This is more complicated.

1 Like
57

The actual script task, mounting might be more complicated indeed but at least the script should equally be executed? Is it a script execution issue or script functionality issue?

1 Like
58

Seems like an execution issue. I tried simply writing to a file to check and it didn’t work. Could be because sysctl-initramfs uses /bin/sh whereas remount-secure uses /bin/bash?

1 Like
59

This worked with /bin/sh although the mounts still don’t.

1 Like
60

Could very well be the reason. Although I was hoping that’s a non-issue:

Could either port to sh or make bash work inside initramfs if that is possible.

Perhaps try this to easily get a shell:

#!/bin/sh
echo remount-secure
sleep 10
sh
sleep 10

The script could run mount before and after running any actual mount commands to see if it actually has any effect. And the sleep 10 (or more) at the end to have a fair chance to read what’s happening. Perhaps the script is functional but then systemd or something is undoing it.

1 Like