On Fri, Nov 10, 2017 at 3:56 PM, Yuraeitha <[email protected]> wrote: > On Friday, November 10, 2017 at 8:09:30 PM UTC, Jean-Philippe Ouellet wrote: >> On Fri, Nov 10, 2017 at 9:22 AM, Yuraeitha <[email protected]> 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. > > > > 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.
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 -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CABQWM_C66Gn1FjmxvSOtzvExZevnZbKgOrCf-pyTMnWRDuXNqg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
