On Tue, 2019-02-12 at 08:08 -0500, Chris Laprise wrote: > 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.
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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/149dec4d462623703ef5549406c0826f5b79ed13.camel%40graumannschaft.org. For more options, visit https://groups.google.com/d/optout.
