storage domain in qubes.

[blacklight]

I have a question about how the images for the vms in qubes are stored.

As one can read in https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf at page 33, Qubes OS was supposed to get a secure storage domain which would be none security critical, but as far as I can see, Qubes VMs still have their root.img's stored in Dom0. why is this? Was there too little time or manpower to implement this in time?  Or maybe a better storage solution was found? I would really like some information about choices made on this subject and any possible future plans about this subject :) .

greetings, 

blacklight

[Jean-Philippe Ouellet]

Relevant:
- https://github.com/QubesOS/qubes-issues/issues/904
- https://github.com/QubesOS/qubes-issues/issues/1293
and some relevant discussion in the list archives that I can't find right now.

Historically the blocking issue has been no way to securely bootstrap
dom0 without depending on the same storage we seek to un-trust. The
"untrusted" storage domain is not really so un-trusted if it
ultimately has full control over the disk and can subvert dom0
integrity for future boots. The actually-worthy-of-trust trusted boot
landscape has changed somewhat recently with e.g. Heads [1][2] and
NERF [3] but since this is still not widely supported (and is not
expected to be any time soon AFAIK) there is still little real
benefit.

As long as that is the case, it's not worth the complexity IMO. Note
however that the storage subsystem API for R4 has still been designed
to be compatible with moving storage out of dom0 in the future.

Regards,
Jean-Philippe

[1]: http://osresearch.net/
[2]: https://github.com/osresearch/heads
[3]: https://www.youtube.com/watch?v=iffTJ1vPCSo

[blacklight]

As long as that is the case, it's not worth the complexity IMO. Note
however that the storage subsystem API for R4 has still been designed
to be compatible with moving storage out of dom0 in the future.

In  https://github.com/QubesOS/qubes-issues/issues/1293 @Marek mentions that it would protect against malicious disk firmware, since this could own Dom0 via an DMA attack, is Qubes currently still vulnerable against this type of an attack?

[Yuraeitha]

You could install a template with a microkernel and slim it down so it barely has nothing installed. For example a minimal template. Then pass through your entire USB controller, assuming you got more than one controller. Typically, many systems have at least two controllers, even laptops, but many also only have only one USB controller. Most modern day motherboards have minimum two controllers by default, without adding extra PCI USB cards with one or more USB controllers.

Basically, if you pass the entire USB controller, then it shouldn't be able to reach dom0 through firmware DMA attacks. But I'm no expert, it's just my understanding of it.

Furthermore, if the USB controller / Card has no PCI reset, then malware may survive when switching between domains. So it may be a good idea to keep this USB controller strictly for that domain only and never move it, if it has no PCI reset feature.

BadUSB? I guess this one can't be avoided even with PCI reset.. at which case, again, keep the same USB controller on the same domain, forever and ever, and you should be okay. Remember to block it in the USB controller from the booting process, as well as in dom0 once booted, so it never touches anything outside the domain, ever.

I'm not sure if each USB controller has their own firmware or if they share firmware with other USB controllers, i.e. on the motherboard or on the same PCI card with multiple USB controllers. Someone who knows more will have to answer that one, if they are separate or not on the firmware level.

[Jean-Philippe Ouellet]

On Fri, Nov 10, 2017 at 9:22 AM, Yuraeitha <yura...@gmail.com> wrote:
> On Friday, November 10, 2017 at 11:38:47 AM UTC, blacklight wrote:
>>> As long as that is the case, it's not worth the complexity IMO. Note
>>> however that the storage subsystem API for R4 has still been designed
>>> to be compatible with moving storage out of dom0 in the future.
>>
>>
>> In https://github.com/QubesOS/qubes-issues/issues/1293 @Marek mentions
>> that it would protect against malicious disk firmware, since this could own
>> Dom0 via an DMA attack, is Qubes currently still vulnerable against this
>> type of an attack?

Yes, that's correct.

> You could install a template with a microkernel and slim it down so it
> barely has nothing installed. For example a minimal template. Then pass
> through your entire USB controller, assuming you got more than one
> controller. Typically, many systems have at least two controllers, even
> laptops, but many also only have only one USB controller. Most modern day
> motherboards have minimum two controllers by default, without adding extra
> PCI USB cards with one or more USB controllers.
>
> Basically, if you pass the entire USB controller, then it shouldn't be able
> to reach dom0 through firmware DMA attacks. But I'm no expert, it's just my
> understanding of it.
>
> Furthermore, if the USB controller / Card has no PCI reset, then malware may
> survive when switching between domains. So it may be a good idea to keep
> this USB controller strictly for that domain only and never move it, if it
> has no PCI reset feature.
>
> BadUSB? I guess this one can't be avoided even with PCI reset.. at which
> case, again, keep the same USB controller on the same domain, forever and
> ever, and you should be okay. Remember to block it in the USB controller
> from the booting process, as well as in dom0 once booted, so it never
> touches anything outside the domain, ever.
>
> I'm not sure if each USB controller has their own firmware or if they share
> firmware with other USB controllers, i.e. on the motherboard or on the same
> PCI card with multiple USB controllers. Someone who knows more will have to
> answer that one, if they are separate or not on the firmware level.

The purpose of an untrusted storage domain is not to guard against USB
devices - those are already isolated via sys-usb.

The goal is to mitigate attacks coming from your internal disk (SSD)
controller or disk firmware, as well as potential attacks against the
storage layers used by Qubes (e.g LVM, etc.).

These are orthogonal.

[Yuraeitha]

oh, I had completely misunderstood, thanks for clarifying.

But then, by that logic, all VM images should be lifted up into a VM, and not only a storage VM. Even just once exposing the drive and it'd be risk an infected, I suppose, in ways similar to the BadUSB. Such security requirements, or hygiene practice if one may, certainly would ban any dual-booting with other operation systems.

Still, this only solves online or threats from files and applications from within the operation system itself. It does supposedly not solve an attacker to shutdown the Laptop/PC, and then inserting an infected firmware attack purposed USB before Qubes even boots, and then infecting the firmware before encryption levels? I'm not sure if that is feasible. But a stateless hardware as suggested by Joanna, start to sound even more appealing given all the hassle this would bring to secure against, and one cannot go all the way, unless its stateless. If I understood it correctly. I mean, an encrypted drive, still should still have its firmware exposed right? Thereby stateless drive is the only known approach to properly work all the way?

[Jean-Philippe Ouellet]

The idea of the storage domain *is* that it would handle all VM
images. You should read the architecture spec if you haven't already.

> Even just once exposing the drive and it'd be risk an
> infected, I suppose, in ways similar to the BadUSB. Such security
> requirements, or hygiene practice if one may, certainly would ban any
> dual-booting with other operation systems.

Hence why I said this being useful depends on a good trusted boot
scheme, which we do not yet have in widespread availability.

> Still, this only solves online or threats from files and applications from
> within the operation system itself. It does supposedly not solve an attacker
> to shutdown the Laptop/PC, and then inserting an infected firmware attack
> purposed USB before Qubes even boots, and then infecting the firmware before
> encryption levels? I'm not sure if that is feasible. But a stateless
> hardware as suggested by Joanna, start to sound even more appealing given
> all the hassle this would bring to secure against, and one cannot go all the
> way, unless its stateless. If I understood it correctly. I mean, an
> encrypted drive, still should still have its firmware exposed right? Thereby
> stateless drive is the only known approach to properly work all the way?

This is why we need integrity checking outside the storage domain,
thus making it untrusted.

This is all covered in the architecture spec:
https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf

Regards,
Jean-Philippe

[Yuraeitha]

Will certainly have a closer look at the pdf during the weekend. Though I would not have posted the original comment had I not misunderstood the storage word like a single VM to put files going in and out. The terminology threw me off, might just be me or my national language. So I did not mean to be rude by not reading the pdf in detail before posting, my apologies.

That said, it looks interesting, I did not realize Qubes has something akin to a user manual.

[Jean-Philippe Ouellet]

No worries at all. Sorry if I seemed dismissive.

> That said, it looks interesting, I did not realize Qubes has something akin
> to a user manual.

Be warned however, some parts are out of date or incorrect.

IMHO that document should be treated more like a discussion of initial
design goals than actual current system documentation because many
things turned out to be implemented differently. It's still a good
introduction to the overall Qubes architecture, particularly paired
with the recent blog posts about the new admin architecture - however
the source code is still your best reference :)

[Yuraeitha]

No problems, it was my fault. It was easy to see my original post as a bit arrogant (there are many who claim to be experts when they are not, I'm really just merely a learner, with a working job and profession into non-computing, so I should think more more carefully before I say anything). I should have worded it better and read the pdf more closely before posting. And if anything, I learned something from you, and you're polite. I really appreciate that :)

I'll keep the out of date in mind while reading it. Still it's a nice way to showcase the Qubes architecture as you say, especially if one wants to recommend Qubes to friends or people you know, who doesn't already know, or know much about Qubes. It'd be nice if Joanna has time to make an updated version one day, but it's a lot to ask for, just for the ability to be able to share more up-to-date single document with friends who do not have the time to go around and read up blogs and email threads. I mean, if they're not hooked on the first older article, perhaps Qubes isn't for them then. Thanks for sharing, I already passed it on to someone I know to read as well, same time as I recommended Qubes to him :)