On Fri, Nov 10, 2017 at 4:44 PM, Yuraeitha <[email protected]> wrote: > On Friday, November 10, 2017 at 9:04:38 PM UTC, Jean-Philippe Ouellet wrote: >> 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 > > 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.
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 :) -- 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_C7PJp3rg5v7UTq8U7_YKvjPrUfY%3DzbSCcD1Mji5PGDbw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
