Preparation for a Qubes Installation: Custom Disk encryption?

[Johannes Graumann]

Gentlepeople,

After playing with it on a secondary machine, I'm looking to transition
from my Arch-setup to Qubes.

I am traditionally choosing to encrypt my file systems using serpent
(considered the strongest entry into the AES competition with slightly
worse speed than the finally choosen Rijndael algorithm) and the
following partitioning:
- UEFI-required EFI System Partition, 512MB, EFI System
- /boot partition (to be encrypted), 512MB, Linux filesystem
- SWAP partition (to be encrypted using a random key), size of RAM
(`free -m`) + 1 MiB, Linux filesystem
- tmp partition (to be encrypted using a random key), 2GB, Linux
filesystem

All but the UEFI partition are being encrypted. '/boot' uses a keyfile
resident in '/' (appropriate grub configuration) and thus PW-protectded
through the encryption of '/'.

Questions:
1) Does that make sense (for Qubes)?
2) Am I missing something necessary?
3) Is there documentation on custom disk encryption and if no: where in
the installation process would I break out (how) to the CLI to get it
done?

Thanks for any hints.

Sincerely, Joh

[Chris Laprise]

On 2/12/19 4:40 AM, Johannes Graumann wrote:
> Gentlepeople,
>
> After playing with it on a secondary machine, I'm looking to transition
> from my Arch-setup to Qubes.
>
> I am traditionally choosing to encrypt my file systems using serpent
> (considered the strongest entry into the AES competition with slightly
> worse speed than the finally choosen Rijndael algorithm) and the
> following partitioning:
> - UEFI-required EFI System Partition, 512MB, EFI System
> - /boot partition (to be encrypted), 512MB, Linux filesystem
> - SWAP partition (to be encrypted using a random key), size of RAM
> (`free -m`) + 1 MiB, Linux filesystem
> - tmp partition (to be encrypted using a random key), 2GB, Linux
> filesystem
>
> All but the UEFI partition are being encrypted. '/boot' uses a keyfile
> resident in '/' (appropriate grub configuration) and thus PW-protectded
> through the encryption of '/'.

FWIW, if you switch to legacy BIOS boot and your system has a TPM you
may be able to use the Qubes anti-evil-maid package to guard against
firmware & boot tampering. Most Qubes users don't seem to opt for it,
but I thought you might be interested in the extra security.

>
> Questions:
> 1) Does that make sense (for Qubes)?

On this topic, the sensibility of encryption options with Qubes is about
the same as for regular Linux distros. Personally, I don't think
switching away from AES is necessary.

> 2) Am I missing something necessary?
> 3) Is there documentation on custom disk encryption and if no: where in
> the installation process would I break out (how) to the CLI to get it
> done?

Qubes uses the RHEL/Fedora installation tool called 'anaconda' which is
documented on the Red Hat and Fedora sites. I don't recall if the
anaconda UI lets you specify the cipher, but the 'kickstart' feature
does so that might be an option.

Also note that a non-AES cipher may seem nearly as quick as AES for
access times, however it will have an impact on multitasking performance
since AES is hardware accelerated while the other ciphers are not on
most systems.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This sounds like what you're looking for:

https://www.qubes-os.org/doc/custom-install/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxjdecACgkQ203TvDlQ
MDBnOBAAljqLh5JK+O1uTHK1DEcGvgpcOMgNOm+r5MfVgUP3Qh3kAPmjidR4npYr
e4Ok/4vk1lP+7W6Nst3y8hoiPXwXwFGthwnjjPp4SQBZsEtY2l3nCq+QyoNKTmjC
iUtqq4IUue+Mp2WFDvzTfeZTSffMseYb5yRl9HPnB+NKnfiPf9LkBGeziETYztpt
woSv6QoULh1f2aUc6PrDH/3ExJot4RB8uZ8z+DlTq56fhcvTnapk20p7yNTwwXd4
T7I961nE3lHqWMgBCAURY2HtQfqd/2NvV8aIVhD/qAIP0f+QjFFpvm9fOVdyTNC/
NR+AKJaUPMvxxea+7d+Z8k3xro7Il+Tj1gI2RGPoooHz3xAvp6mnHSVr5fGE93fk
t3wkM4tS2ttPN4Un53EpDwXbqvbWvPdXqnv92zPU+e1Kz3OsZto4vkYiBtd0XErp
pUAvNFqEb4e3o/1TB2FYL2feQkFp9lUMoYT0AUCDNRvyu/tKm5QcblYO5lTiKQW8
KArf7ly5F++9J7kb5q8IjPXMF+24gtGi6HYvI5/qJg5hDh87+C3mluqNJe++JdFc
rZAvc5xAHZFsU55T8a2Unve2KlzDZvj8qLuxGFL8BPZTyI7fYl7rxWhL4nnmQjWP
+gLH3EKXenL3sUQzbuk9j1n9pF3c9/qXJfwozv+8/HjP1Gm9uSk=
=biVv
-----END PGP SIGNATURE-----

[Johannes Graumann]

So after I was pointed by @ADW at
https://www.qubes-os.org/doc/custom-install/, I'm well set up to tackle
any customization - I'm aware of the hardware acceleration generally
baked in for AES algorithms. Yet the question remains whether swap and
especially tmp partitions make sense from a Qubes-perspective. I assume
that given the RAM management necessary, swap for dom0 may be quite
sensible (is RAM+ 1MB an appropriate size?), but how about tmp? I
realize that the my use case, where I traditionally have browsers etc.
use it as a download directory that's automatically purged upon
machine shutdown does not make a whole lot of sense for dom0. Is there
anything Qubes-specific to keep in mind when deciding on whether a
separate tmp partition is adding security?

Sincerely, Joh