Questions about Beta 2 and disc partitioning
Tommaso Gagliardoni
am now playing around with Qubes. Please accept my apologizes: I really
love this project, and I have some experience with linux, but Qubes is
so different from what I'm used to, that sometimes it seems to me like
learning to use an OS from zero, hence my questions could sound naives.
The first question I have is: I've heard that Qubes Beta 2 is incoming,
is it worthwhile to wait or is it still a long time to go? I have one of
the latest processors, and am not sure Xen 3.4 can handle Vt-d well on it.
Second: I have two discs installed, a 120 GB mSATA SSD (40 GB free) and
a 320 GB HD. I'd like to hear from you some advice on how to best
partition my system for Qubes (i.e.: where do I put swap and /tmp ? Does
it matter? etc.). I've read the Qubes Architecture Details PDF, but it
is still not clear to me what happens if, during installation, I choose
to opt for a separate /tmp or swap or /whatever: which of my AppVMs will
have access to these devices by default? Are swap and /tmp partitions
kept in common between the various domains? Does it make sense to have a
separate swap or /tmp partition encrypted with a random key via
LUKS/cryptsetup to clear them at every reboot?
Third question: on my laptop systems I was used to encrypt every
partition except for a small /boot. If I got it correctly, with Qubes
this is not necessary, because all sensitive data are encrypted already,
while the rest of the system is resistant to alterations. Is this
correct? How should I partition discs if, nonetheless, I want to have a
full disk encryption?
Last question: to achieve some protection against Evil Maids (and also
to get a certain degree of "practical" plausible deniability) I have
been using this trick: I install a cleartext decoy system in /dev/sda1,
and the "real" system in encrypted partitions starting from /dev/sda2.
Then I install /boot and bootloader on a separate USB key, select the
USB drive as primary boot device in BIOS options, and /dev/sda as
secondary. In this way, e.g., when I turn on the computer without
inserting my key, the decoy system boots, while if the key is inserted I
am asked for the passphrase to unlock the other system. Is there any
reason why this would be a Bad Idea with Qubes? If not, should I put
into my USB key just the bootloader or the entire /boot partition too?
Thanks for any help and congratulations for the project!
--
Tommaso Gagliardoni
GnuPG Key ID: 51D8DEB8
Fingerprint: DC10 0D2F 8F07 238D C5DB 63B8 0AEF 48C5 51D8 DEB8
Radoslaw Szkodzinski
<tom...@gagliardoni.net> wrote:
> Hi, I've finally solved the installation issue on my Thinkpad X220 and
> am now playing around with Qubes. Please accept my apologizes: I really
> love this project, and I have some experience with linux, but Qubes is
> so different from what I'm used to, that sometimes it seems to me like
> learning to use an OS from zero, hence my questions could sound naives.
>
> The first question I have is: I've heard that Qubes Beta 2 is incoming,
> is it worthwhile to wait or is it still a long time to go? I have one of
> the latest processors, and am not sure Xen 3.4 can handle Vt-d well on it.
Xen 3.4 has a critical bug in VT-d handling on certain "older" CPUs
(such as yours), making it bypassable. I'm not sure the fix has been
backported.
> Second: I have two discs installed, a 120 GB mSATA SSD (40 GB free) and
> a 320 GB HD. I'd like to hear from you some advice on how to best
> partition my system for Qubes (i.e.: where do I put swap and /tmp ? Does
> it matter? etc.).
For performance, SSD will be best of course. Not that Qubes should
wear it down, in fact it should spare it more than typical
distributions. You'll need plenty of disk space, as the VMs aren't all
that tiny yet.
> I've read the Qubes Architecture Details PDF, but it
> is still not clear to me what happens if, during installation, I choose
> to opt for a separate /tmp or swap or /whatever: which of my AppVMs will
> have access to these devices by default? Are swap and /tmp partitions
> kept in common between the various domains? Does it make sense to have a
> separate swap or /tmp partition encrypted with a random key via
> LUKS/cryptsetup to clear them at every reboot?
No, each AppVM has a separate /tmp and no swap. Dom0 /tmp and swap are
configurable, however the VMs will never be swapped out as Xen 3.4
doesn't support that (that's why 8GB RAM is strongly recommended; 4 GB
is bare minimum for a few VMs). It might be possible to overcommit
memory with Xen 4, but I'm not sure what good would that do without
the latest kernel's cleancache (formerly tmem).
New Beta2 VMs should consume less memory, hopefully.
> Third question: on my laptop systems I was used to encrypt every
> partition except for a small /boot. If I got it correctly, with Qubes
> this is not necessary, because all sensitive data are encrypted already,
> while the rest of the system is resistant to alterations. Is this
> correct? How should I partition discs if, nonetheless, I want to have a
> full disk encryption?
No, the data is encrypted only if you encrypt the disk/partitions,
such as by using Anaconda's disk encryption support. Qubes tools don't
encrypt the AppVMs themselves. Not encrypting the root filesystem is a
risk for an Evil Maid attack anyway, much worse than just the
bootloader.
> Last question: to achieve some protection against Evil Maids (and also
> to get a certain degree of "practical" plausible deniability) I have
> been using this trick: I install a cleartext decoy system in /dev/sda1,
> and the "real" system in encrypted partitions starting from /dev/sda2.
> Then I install /boot and bootloader on a separate USB key, select the
> USB drive as primary boot device in BIOS options, and /dev/sda as
> secondary. In this way, e.g., when I turn on the computer without
> inserting my key, the decoy system boots, while if the key is inserted I
> am asked for the passphrase to unlock the other system. Is there any
> reason why this would be a Bad Idea with Qubes? If not, should I put
> into my USB key just the bootloader or the entire /boot partition too?
The trick with USB key is good, however plausible deniability doesn't
work this way. You'd need to default to the HDD one to not raise
suspicions,
perhaps using BIOS boot menu to pick the pendrive manually on every boot.
To counter the Evil Maid attack, you must never leave the pendrive out
of sight where an attacker might be able to steal it.
Also, thanks for telling everyone - this will ruin any deniability you
might have had. :) Should've posted anonymously.
Regards,
--
Radosław Szkodziński
Marek Marczykowski
> On Mon, Aug 22, 2011 at 3:30 PM, Tommaso Gagliardoni
> <tom...@gagliardoni.net> wrote:
>> Hi, I've finally solved the installation issue on my Thinkpad X220 and
>> am now playing around with Qubes. Please accept my apologizes: I really
>> love this project, and I have some experience with linux, but Qubes is
>> so different from what I'm used to, that sometimes it seems to me like
>> learning to use an OS from zero, hence my questions could sound naives.
>>
>> The first question I have is: I've heard that Qubes Beta 2 is incoming,
>> is it worthwhile to wait or is it still a long time to go? I have one of
>> the latest processors, and am not sure Xen 3.4 can handle Vt-d well on it.
>
> Xen 3.4 has a critical bug in VT-d handling on certain "older" CPUs
> (such as yours), making it bypassable. I'm not sure the fix has been
> backported.
Yes, it is included in our xen-hypervisor-3.4.3-9 package (available as
update after installation).
>> I've read the Qubes Architecture Details PDF, but it
>> is still not clear to me what happens if, during installation, I choose
>> to opt for a separate /tmp or swap or /whatever: which of my AppVMs will
>> have access to these devices by default? Are swap and /tmp partitions
>> kept in common between the various domains? Does it make sense to have a
>> separate swap or /tmp partition encrypted with a random key via
>> LUKS/cryptsetup to clear them at every reboot?
>
> No, each AppVM has a separate /tmp and no swap.
This is not fully true - each VM have own swap (1GB, in sparse file),
but doesn't use swap from dom0.
> Dom0 /tmp and swap are
> configurable, however the VMs will never be swapped out as Xen 3.4
> doesn't support that (that's why 8GB RAM is strongly recommended; 4 GB
> is bare minimum for a few VMs). It might be possible to overcommit
> memory with Xen 4, but I'm not sure what good would that do without
> the latest kernel's cleancache (formerly tmem).
tmem can be used as (clean)cache backend and/or extension to swap
(obviously much faster). But it isn't currently done in Qubes (even beta2).
> New Beta2 VMs should consume less memory, hopefully.
>
>> Third question: on my laptop systems I was used to encrypt every
>> partition except for a small /boot. If I got it correctly, with Qubes
>> this is not necessary, because all sensitive data are encrypted already,
>> while the rest of the system is resistant to alterations. Is this
>> correct? How should I partition discs if, nonetheless, I want to have a
>> full disk encryption?
>
> No, the data is encrypted only if you encrypt the disk/partitions,
> such as by using Anaconda's disk encryption support. Qubes tools don't
> encrypt the AppVMs themselves. Not encrypting the root filesystem is a
> risk for an Evil Maid attack anyway, much worse than just the
> bootloader.
Exactly.
--
Pozdrawiam / Best Regards,
Marek Marczykowski | RLU #390519
marmarek at mimuw edu pl | xmpp:marmarek at staszic waw pl
coderman
<astra...@gmail.com> wrote:
> ...
> To counter the Evil Maid attack, you must never leave the pendrive out
> of sight where an attacker might be able to steal it.
use iso media for this read only, tamper evident enforcement
(more or less. some usb storage have a read-only switch to fix)
be aware you may need to manually fix issues with initrd size or
adjust kernel+initramfs to make isoboot happy which grub/lilo don't
require.
> this will ruin any deniability you
> might have had. :)
plausibly deniable OS / VM partitions are a myth! for most this
doesn't matter. [0]
boot to No Operating System Found or block at passphrase prompt...
0. until we get a decent steganographic file system this will remain
the case. and the price/overhead steep!