why remount-secure even needed? fix insecure mount options at the root, not here

[adrelanos]

Which software / source code sets the initial insecure mount options anyhow?

Could we fix it there instead of adding a band-aid on top?

[monsieuremre]

Well, actually there is a better way. A solution that is no band-aid. And it is modifiying the fstab. There is also another solution, that is direct and involves no remounting. We can write custom systemd mount targets and ship them with the package. The only problem with the latter is, fstab entries take precedence over those units. So we can't harden what is covered in fstab with this way.

[monsieuremre]

Like if the user has a seperate /home volume, we can't harden it with our custom systemd unit. I think the reason behind this is, systemd dynamically overrides our unit with the unit it auto generates from fstab on startup.

[adrelanos]

That doesn't really answer why it's insecure by Debian (or most Linux distributions) default.

[monsieuremre]

Because by default debian and most distributions don't do too much disk partitioning. If you want a seperate tmp or var partition, most of the time you manually configure them when installing. And bind mounting to itself is clever workaround to get all the good mounting option benefits without having the partition itself, but it is really not that surprising that no distro would mount a directory to itself by default.

[monsieuremre]

A very highly unrelated sidenote: the only distribution that I see who ships secure defaults by default is openSUSE. Debian by default ships with very slack file permissions for anything. OpenSUSE however ships with already mostly hardened defaults. Tumbleweed gets a score of 87 on lynis after a default install. Debian and most other distros get like 60. And this isn't surprising, because Debian does not try to be better desktop or server os. Debian tries to be the universal os, compatible with every device ever. So actually makes sense for them to ship slack defaults. A price to pay for universal compatibility.

[adrelanos]

Where is the source code where it says "use these default mount options for this and that partition"?

[adrelanos]

Like if the user has a seperate /home volume, we can't harden it with our custom systemd unit. I think the reason behind this is, systemd dynamically overrides our unit with the unit it auto generates from fstab on startup.

Created #161 for it.

[adrelanos]

quote https://lists.freedesktop.org/archives/systemd-devel/2019-December/043845.html

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.

This might be the referenced source file:
https://github.com/hramrach/systemd-1/blob/master/src/core/mount-setup.c

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.

This implies that initramfs (initramfs-tools, dracut) is responsible for mount options too.

[monsieuremre]

Ok I tell you the source. Systemd calls the binart mount with the option --all on boot. And mount, unless the mount options are overriden with the option --option or -o, looks for the options in the fstab file, which by default has the path /etc/fstab. What we can do is:

• We modify the mount package. Uninstall the one packaged by debian, package our own, modify the source, make the fstab path default to /something/kicksecure/fstab, and the world is good.
• Modify the calling of mount --all, and make it be called with mount --all --fstab /something/kicksecure/fstab.
• Don't play any games and just override the fstab, for simplicity.

These would not be necessary for stuff that have no entries in fstab. Like if the use has no seperate partition for var, we can create a var.mount systemd unit and define our default options there and life would be easy. But unfortunately, if there is a var entry in fstab, our unit will be overridden.

[adrelanos]

But dracut earlier also already uses mount? Or do you mean the systemd which already runs during dracut?

I couldn't find yet the mount options that dracut uses.

[monsieuremre]

When you mount, if you do -o or --options, then you define options, overriding what was the default. If you don't override, then mount looks into fstab for the options. When no options there, then it looks to the respective systemd unit. If it doesn't exist too, then it gives out an error. This is my understanding.

[adrelanos]

At least 3 different things we could accomplish here.

• A) Harden mount options of newly built Kicksecure (or Whonix) VM images. And/or,
• B) Harden mount options of newly built Kicksecure (or Whonix) ISO images. And/or,
• C) Harden mount options of arbitrary systems (such as a Debian based server which gets distribution morphed into Kicksecure).

In case of A),

• for non-Qubes Kicksecure based, the question is why isn't /etc/fstab hardened by default. It's because it's built by grml-debootstrap's (in Debian) chroot-script.
  • We could contribute to grml-debootstrap to harden /etc/fstab as much as possible as upstream accepts as well as add an option --hardened-fstab or --custom-fstab or something like this with an alternative version that hardens it even more (such as in case upstream does not want to mount /home with noexec by default).
• in case of Qubes, their /etc/fstab is here and I've recently sent a PR to improve formatting of /etc/fstab QubesOS/qubes-core-agent-linux#472 which will maybe be the basis for further improvements.
  • Qubes may or may not accept /home mounted with noexec by default.
  • Related tickets:
    • Mount /rw and /home with nosuid + nodev QubesOS/qubes-issues#5263
    • mount /tmp /var/tmp /dev/shm with nodev nosuid QubesOS/qubes-issues#5329

In case of B),

• When installing, it will be probably calamares based. So calamares installer would create /etc/fstab, we'd need to look into how calamares handles that, contribute upstream or write a custom calamares module. But that is blocked until an ISO emerges. (Btw progress was made there recently on ISO building, see deriative-maker help-steps/image-to-iso.)

In case of C),

directly writing to /etc/fstab from security-misc is risky. Hence such a systemd unit + script makes sense.

[adrelanos]

dracut also supports /etc/fstab.sys. Not well documented. But can be seen in dracut source code.