Qubes-VM-hardening
Qubes-VM-hardening copied to clipboard
tasket
run after qubes-mount-dirs.service for code simplification?
- 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?
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.
