On Tue, Aug 09, 2016 at 08:40:15PM +0200, Marek Marczykowski-Górecki wrote: > On Tue, Aug 09, 2016 at 08:32:39AM -0600, Trammell Hudson wrote: > > I'd like to configure my Qubes installation to have a read-only and > > dm-verity protected / and /boot partitions for the hypervisor, dom0, > > qubes configurations and templates, with a separate read-write partition > > for the user data and volatile portions protected by a sealed TPM key. > > This is very interesting setup! Please tell us if you manage to do it.
Assuming it all works, I'll be doing a writeup and hopefully a CCC talk on the configuraiton. The coreboot parts are working really well now -- the root of trust is setup in the romstage, which can be protected by the SPI flash chip's WP# and BP bits to prevent software updates (although still a potential evil maid risk). All of the CBFS entries are measured before they are executed or unpacked, which includes MRC, SMM, and the Linux kernel/initrd. tpmtop runs in the Linux payload and if the TPM can unseal the TOTP secret, it attests that the system is a hopefully good state. Also in the ROM is a GPG keyring with public signing keys. The /boot partition is protected with dm-verity, the root hash signature is verified with GPG, the xen.gz, vmlinuz and initrd can also be signed and verified. The private key is in a Yubikey, so updates to that partition will require the hardware token to resign the hashes. And then Qubes starts up and the hard parts begin... > > In the "VM Settings" - "Advanced" tab the "Paths" do not seem to > > be editable. I could edit the file by hand after setting up Qubes, > > although if there is an official way to do it during installation or > > after-the-fact that would be nicer. > > There is no supported way for changing those path. Is it possible to change them at all? Even when I edit the /var/lib/qubes/appvms/personal/personal.conf file, after I start the VM with qvm-start it appears that the file is re-written (my changes are gone and the paths are back to the defaults). Is there a reason to recreate the file instead of using its contents? > [...] > Also search the list archive for relocating volatile.img files - AFAIR > there was some script for that. It looks like a symlink for the private.img file will work, but the volatile.img is always re-created. I see the post that modifies the /usr/lib/qubes/prepare-volatile-img.sh, so maybe those two are sufficient to migrate the files from / to /home. -- Trammell -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20160812031735.GM16348%40chishio.swcp.com. For more options, visit https://groups.google.com/d/optout.
