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.

[monsieuremre]

Yeah I don't think that will work. Pushing to debian upstream. Like it might, but the debian team is very unresponsive unless it is a bug fix. It would happen probably, but like, in about 3 debian releases later. We can just make our own good defaults ISO. Which isn't that hard to be honest. I feel like we are on our own for the most part tho.

I don't want to take every opportunity to shill suse, so I'm sorry. But opensuse puts in effort to harden their default fstab entries.

[adrelanos]

Pushing to debian upstream. Like it might, but the debian team is very unresponsive unless it is a bug fix. It would happen probably, but like, in about 3 debian releases later.

Debian isn't a conglomerate. It depends on the individual packages, maintainers. I was talking about grml-debootstrap. Pushing fixes to grml-debootstrap seems entirely doable. I managed to land a few patches in grml-debootstrap. The only condition is that it needs to be clean, high quality code. You can see my commits here:
https://github.com/grml/grml-debootstrap/commits/master

It doesn't take long either until it reaches derivative-maker. I copied grml-debootstrap to derivative-maker source code folder. A soft fork if you want so. (Not with the intention splitting from upstream due to disagreement or running a separate project. Just to make the updated code available earlier in derivative-maker waiting for the next major Debian release. No big story.)

grml-debootstrap recently learned arm64 support which was contributed by a Whonix contributor. Upstream grml-debootstrap took even did the cleanup / refactoring commits. Building VM images with EFI and Secure Boot was also recently contributed and merged by another contributor.

Until now, grml-debootstrap upstream is entirely reasonable. I might even be capable of running a "full fork" of grml-debootstrap should upstream disappear which I don't hope because they've been doing great work for years.

Improving grml-debootstrap fstab will result in improved Kicksecure VM images. (Would also be possible to leave grml-debootstrap as is and add a better fstab at the derivative-maker level only but that would be more hacky and less beneficial for the overall ecosystem, less use and testing, less bugs only happening inside Kicksecure and derivatives.)

Non-responsiveness of other Debian maintainers is inapplicable here.