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

Development
,
28

/run/user/1000 bypasses /run’s noexec as it is its own mount point. We might want to look into restricting that too.

It could be useful to mount /dev with noexec.

We should experiment with the ro mount option to mount directories as read-only. /sys would be a good one for this as most things don’t need to write to it.

More mount points we can restrict are:

mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)

CLIP OS’s fstab is here products_clipos/40_fstab.sh at master · clipos/products_clipos · GitHub

1 Like
29

I can merge that but it won’t help much. The current implementation is a dead-end. It’s needs to be replaced entirely. See my previous post. There I link to my question, the bug description and reply by systemd.

1 Like
30

The 2 alternative methods talked about in that link are using /etc/fstab or systemd .mount files. We’ve already looked into both of these when creating proc-hidepid and neither worked for us.

1 Like
31

Then we need to produce good questions and ask the systemd developers more. The current implementation is a dead-end indeed. My question on the mailing list perhaps doesn’t reflect it how bad it is. It causes horrible race conditions. Hard to debug. Random things break at random time. It’s really not ready for production.

1 Like
32

The race conditions can be fixed by scrapping the systemd service and running it in the initramfs. This also goes in line with what the guy on the mailing list said:

Have it run before systemd (i.e. do it from the initramfs)

How would debugging be a problem? Make a list of everything it does and write it to /var/log/remount-secure.log.

33

What remount-secure does is easy to log indeed. That always worked. What was hard to debug was some random unrelated service breaking.

That would be a good solution.

Before piling up more and more initramfs stuff, could you port all of Whonix to dracut and implement this using a dracut hook?

1 Like
34

I’ve no experience with dracut and an initramfs-tools hook would still be needed even if we do switch to dracut, for ordinary Debian compatibility as security-misc isn’t Whonix-specific.

1 Like
35

dracut is a replacement for initramfs-tools if I am not mistaken.
initramfs-tools hooks would need to be replaced by a dracut hook.

1 Like
36

Yes, but normal Debian users won’t be using dracut so we’d need to have hooks for both so they can still use security-misc.

1 Like
37

Also normal Debian users can use dracut. It’s a well supported Debian package. Dunno which initramfs generator is default for Deiban now or in future initramfs-tools vs dracut.

I am not sure how much it’s worth spending effort on supporting security-misc for plain Debian, non-Kicksecure users.

Linux user account hardening (pam, su, sudo) is causing trouble.

  • at least 1 user needs to be in group sudo - otherwise security-misc aborts installation
  • previous manual pam modifications can break:

That could be a lot effort for a small number of users.

1 Like
38

initramfs-tools hooks are trivial. It’s a minor thing that would make security-misc far more compatible.

1 Like
39

I figured it out.

Now we just need to figure out how to get the /tmp, /dev/shm and /run restrictions to work.

1 Like
40

/run is mounted in the initramfs and is moved to the rootfs just after the init-bottom scripts are executed so we can create an init-bottom initramfs hook to remount /run with the mount options.

1 Like
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