run after qubes-mount-dirs.service for code simplification?

[adrelanos]

• https://github.com/tasket/Qubes-VM-hardening/blob/master/vm-boot-protect.service

[Unit]
After=qubes-sysinit.service
Before=qubes-mount-dirs.service

• https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/qubes-mount-dirs.service

After=qubes-sysinit.service dev-xvdb.device
DefaultDependencies=no
Before=local-fs.target rw.mount home.mount qubes-gui-agent.service

• https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/mount-dirs.sh

The issue with mount-dirs.sh is that it calls /usr/lib/qubes/init/bind-dirs.sh which could execute malicious code through /rw/config/qubes-bind-dirs.d which during a previous boot could have used to place a malicious malware hook. But that's something that can be fixed upstream in Qubes by moving bind-dirs into its own systemd unit file.

Assuming that is sorted out upstream in Qubes, then Qubes-VM-Hardening could use:

[Unit]
After=qubes-mount-dirs.service qubes-bind-dirs.service
Before=local-fs.target rw.mount home.mount qubes-gui-agent.service

Dunno if it would also need DefaultDependencies=no.

Thereby Qubes-VM-Hardening could do its thing while not risking that any applications process any potentially maliciously modified files in the private image? Then Qubes-VM-Hardening could be simplified and wouldn't require to use mount / umount itself? Do you see any loopholes in this approach?

[tasket]

My initial thought is that vm-boot-protect can't go after qubes-bind-dirs in any case, so the latter would have to go on the Before= line. And if we're letting qubes-mount-dirs handle all mounting, then I don't think rw.mount or home.mount can be on Before= line.

FWIW, this question about having upstream create a separate qubes-bind-dirs came up before. But at the time I saw no other reason for them to change, and I wanted to do what was both expedient and safe.

[adrelanos]

Created QubesOS/qubes-issues#5256 for it.