On Oct 04, 2016, at 07:45 pm, Marek Marczykowski-Górecki
<marma...@invisiblethingslab.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Oct 04, 2016 at 06:36:19PM +1000, ileyd wrote:
On 4 Oct. 2016, at 3:48 pm, ileyd <il...@icloud.com> wrote:
From: ileyd <il...@icloud.com>
Date: 4 October 2016 at 3:43:45 pm AEST
To: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com>
Subject: Re: [qubes-devel] What prevents use of a storage driver domain?
On 3 Oct. 2016, at 6:33 pm, Marek Marczykowski-Górecki
<marma...@invisiblethingslab.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Oct 02, 2016 at 01:25:19AM +0000, Adin Kapul wrote:
Hi,
I am curious what prevents (even if not completely untrusted) implementation of
a storage driver domain.
It is discussed in the architecture document, and has been alluded to by
Joanna, so I'd assume that this is an eventual aim of the Qubes project.
The process is relatively simple on stock Xen, and Qubes already supports using
AppVMs as storage driver domains to serve locally-stored images (just as Dom0
stores guest images) to other guests, so I'm curious what obstacles there are
to implementing this for the main guest storage, or is it simply a case of it
not being a priority and no one having worked on it?
Moving all the storage to separate domain means that dom0 have no direct
access to hard drive. This makes boot process much more complex - for
example dom0 also needs to be booted somehow - to start that storage
domain. This, to be meaningful in any way, require working trusted boot.
And given problems with Intel ME and TXT implementation, there is no
hardware providing it.
Could you elaborate on what you said?
Would the boot process really be made very much more complex? The storage
domain root needs to be stored separately so that it may be accessed at boot
time, and the storage domain would need to be started by the initramfs. Neither
of these would be particularly challenging, would they? Dom0's storage would
still appear as normal block devices to it, so it shouldn't affect the boot
process after that. There is no need for a fully booted dom0; all the necessary
bootstrapping could easily occur in a dom0 initramfs.
But you need things like boot configuration (what should be started as
storage domain, apply updates etc), key management (as explained in
architecture). Also fitting everything needed to start a domain in
initramfs will make that initramfs much larger (which can be a problem
in some cases[1]). And some components (like xenstored) cannot be
restarted, so you'll be left with processes still running with initramfs
as rootfs, even after switching to normal root (or you'll need to
implement switch root in such components).
This all is of course doable, but complex. So, we think it worth going
that way only if it's meaningful increase of system security.
Could you additionally elaborate on why full trusted boot is an absolute
necessity for this to be meaningful at all? I am aware of course that without a
separate encryption VM, this domain would be in a very trusted position, able
to modify all root file systems.
Exactly. Including boot images (xen, dom0 kernel, initramfs etc) (*). This
means compromised storage domain is basically full system compromise. So
there will be no gain from separating it, besides making things more
complex.
Just to clarify - properly done storage domain would separate two things
out of TCB:
- disk backend drivers (xen-blkback), exposing disks to VMs
- storage subsystem (SATA controller, firmware, drivers)
Any of those can compromise storage domain, so it makes sense only when
compromised storage domain can not break into other components.
What do you mean by your comment on the problems with ME and TXT?
For example this list:
http://invisiblethingslab.com/itl/Resources.html
Or article linked here:
http://blog.invisiblethings.org/2015/10/27/x86_harmful.html
To clarify, how I imagine this working:
• dom0 initramfs contains minimal xen toolstack
• storage domain initramfs available as file in dom0 initramfs
Dom0 initramfs boots as normal up until where it would usually switch to new
root
Dom 0 starts storage domain using the initramfs available
Storage domain boots as normal having full access to all disks, mounts root
from disk
Dom0 mounts root from storage domain
Dom0 switches to new root and boots as normal
Something like this (but see my earlier comment).
(*) You could say - lets keep them on separate device, connected only at
boot time. Yes, this will improve some things, but will not solve all
the problems. For example such system would be still vulnerable to
backdoored SATA controller firmware (which can subvert boot process
using DMA, even when booting from other devices). Or malicious BIOS
(either backdoored by vendor, or reflashed later).
And you still need to connect this device sometimes, to apply updates,
modify configuration etc. At this time, whatever you use to sandbox
this subsystem (USB VM, storage domain etc), it can compromise that
device, which - without working trusted boot - may be left unnoticed.
[1]
https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-135988806
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJX83pKAAoJENuP0xzK19csLmIIAIpj//wMlnthHkplY+L/MM+H
m++9FjO5ahVWeQS50+0DEQRhrJws8koRdz0BvK716SooDYsJLzgpKnJrVxUmTx6+
7N31p4j3FHnxYhy5YQ8/QFjLUo+SBjlf4Q7tQUgs54FWGgYfXin68/0b0WVMJGTx
+B95PFcnt7PA+v1MqTUHL7kiS6ssaEgXxJVUwZTY2gaLYnh3BUWQ48Z7IzOPB+l+
m3m322GEpRIRm5+OibXu/+5S7JJWE6iuv2sf3gJ1rGcjX6/emSf/NXrIFNfjufKW
vrOXdE2G1oJUmtPzlUjubny+IyJIyfoYQm5D+6xVUvBqgUIrgvevuTeEryKVWa4=
=6lsD
-----END PGP SIGNATURE-----
--
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 qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/20161004094546.GL2436%40mail-itl.
For more options, visit https://groups.google.com/d/optout.
Hi,
Could you additionally elaborate on why full trusted boot is an absolute
necessity for this to be meaningful at all? I am aware of course that without a
separate encryption VM, this domain would be in a very trusted position, able
to modify all root file systems.
Exactly. Including boot images (xen, dom0 kernel, initramfs etc) (*). This
means compromised storage domain is basically full system compromise. So
there will be no gain from separating it, besides making things more
complex.
That is true. Though if the encryption domain is separated from the disk
controller one, I still don't see why trusted boot is necessary, for there to
be any benefit (making disk controller drivers untrusted; their compromise
unable to lead to full system compromise) to this. See below for what I mean
by this, with dm-crypt running in a separate domain to that which has direct
access to disks:
Just to clarify - properly done storage domain would separate two things
out of TCB:
- disk backend drivers (xen-blkback), exposing disks to VMs
- storage subsystem (SATA controller, firmware, drivers)
Any of those can compromise storage domain, so it makes sense only when
compromised storage domain can not break into other components.
Does the depiction above satisfy that? In such a scenario, the domain with
direct access to the disks, running the disk controller drivers, etc, would not
be in a position to modify (authenticated encryption may be necessary to ensure
this) nor read the contents. Obviously though this raises questions as to how
to handle key storage for the dm-crypt domain, perhaps making use of sealed
secrets in the TPM.
What do you mean by your comment on the problems with ME and TXT?
For example this list:
http://invisiblethingslab.com/itl/Resources.html
Or article linked here:
http://blog.invisiblethings.org/2015/10/27/x86_harmful.html
Does this mean that the position taken by the Qubes project towards Intel ME
and TXT, is that they are completely useless and there is not much point to
making use of them? If so, what benefits are afforded by AEM, and is it
planned to be deprecated? If not, considering it is the only form of trusted
boot available an commodity hardware at the moment, would it not satisfy the
requirements of trusted boot for a storage domain?
Something like this (but see my earlier comment).
(*) You could say - lets keep them on separate device, connected only at
boot time. Yes, this will improve some things, but will not solve all
the problems. For example such system would be still vulnerable to
backdoored SATA controller firmware (which can subvert boot process
using DMA, even when booting from other devices). Or malicious BIOS
(either backdoored by vendor, or reflashed later).
And you still need to connect this device sometimes, to apply updates,
modify configuration etc. At this time, whatever you use to sandbox
this subsystem (USB VM, storage domain etc), it can compromise that
device, which - without working trusted boot - may be left unnoticed.
I would imagine the initramfs would be stored on the normal /boot partition,
with its integrity verified/enforced through Intel TXT (sealed secrets), and
optionally UEFI Secure Boot (which some implementations of have been shown to
have vulnerabilities allowing it to be bypassed, I am aware), though storing it
on an external device like is suggested with AEM would limit the opportunity
for the contents to be modified. See above for comment on threat of initramfs
compromise without working trusted boot. With system and disk controller
firmware backdooring, assuming signed firmware updating, surely a limited
degree of implicit trust must be placed in the firmware vendors, considering
these are threats that still presently apply to Qubes and potentially result in
full system compromise?
I guess your central point here, is that the introduction of a storage domain
would be a non-negligible development effort, and the perceived benefits of
such are minimal if any. The main benefit I see to this, is that it allows for
the storage controller drivers to be removed from dom0, and so their compromise
would no longer lead to a full system compromise, but a denial of service
attack at worst. This keeps with the aim of dom0 disaggregation, and removes
an avenue for system compromise (this would leave only the audio, graphics, and
input drivers in dom0, wouldn't it?). A potential other benefit, though
unlikely at the moment, would be that if dom0 were not permitted full control
(this would likely require use of XSM policy as well; potentially see OpenXT
for reference) over the encryption domain, it would allow for dom0 to never
have access to key material, requiring a separate compromise of that domain to
exfiltrate them.
Warm Regards.
ileyd
--
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 qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/1b43e947-6063-47ef-aba6-21fa6a328ad5%40me.com.
For more options, visit https://groups.google.com/d/optout.
