Qubes-VM-hardening
Qubes-VM-hardening copied to clipboard
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.
Created https://github.com/QubesOS/qubes-issues/issues/5256 for it.