implement as systemd unit file

[adrelanos]

Great stuff!

I think it would be better implemented as systemd unit file that call a script. That way users don't have to manually copy and overwrite rc.local. Then this could be packaged and installed using a package manager.

[tasket]

I'll post my systemd version today (unfortunately, it seems to trigger a race condition in qubes-db.service which is why I started thread in qubes-dev).

[tasket]

https://github.com/tasket/Qubes-VM-hardening/tree/systemd

Needs testing/tweaking. Issue vs other startup units here... https://groups.google.com/d/msgid/qubes-devel/c2709168-212e-a06c-7d43-70c94a79761d%40openmailbox.org

[tasket]

@adrelanos I have it working well in Debian 9 and Whonix. But shouldn't use vm-sudo-protect-root option with Whonix which needs the root-owned /rw files intact.

[adrelanos]

tasket:

But shouldn't use vm-sudo-protect-root option with Whonix which needs the root-owned /rw files intact

Could you please elaborate on that?

[tasket]

@adrelanos That Qubes service option causes the script to delete the following folders during startup: /rw/config /rw/usrlocal /rw/bind-dirs

This is explained in the readme and prevents those dir contents from affecting the execution environment at VM startup, giving a template-based VM a chance to boot cleanly even if an attacker acquired root in the past.

If your VMs need those /rw folders, specify the 'vm-sudo-protect' Qubes service instead (sans -root) which will only apply immutable settings to script objects in /home/user.

[adrelanos]

tasket:

@adrelanos That Qubes service option causes the script to delete the following folders during startup: /rw/config /rw/usrlocal /rw/bind-dirs

This is explained in the readme and prevents those dir contents from affecting the execution environment at VM startup, giving a template-based VM a chance to boot cleanly even if an attacker acquired root in the past.

If your VMs need those /rw folders, specify the 'vm-sudo-protect' Qubes service instead (sans -root) which will only apply immutable settings to script objects in /home/user.

I see. Well, perhaps it could be covered in docs how to manually sanitize these folders during disaster recovery? For most users, there should be very few files inside there and even less legit executable stuff.

[tasket]

@adrelanos The .service file currently uses OnFailure=shutdown.target which operates after checksumming failed and user has closed the xterm window. Let me know if you have any preferences about the systemd unit.

[adrelanos]

I don't like auto shutdown on issues. Imagine xterm won't start either for some reason. Then you have a VM that is even hard to boot and makes it even hard to debug using dom0 sudo xl console vm-name since it keeps automatically quickly shutting down.

[tasket]

I guess it seemed easier to test for me. But for release I'll change it to emergency.target or nothing at all (boot would resume on closing the terminal).

[tasket]

@adrelanos I have an idea for handling the failure mode that doesn't set a new target. See issue #7 where this is addressed.

I'll close this for now since the basic systemd work is done.