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] > <javascript:>> 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 > <https://www.google.com/url?q=https%3A%2F%2Fwww.qubes-os.org%2Fattachment%2Fwiki%2FQubesArchitecture%2Farch-spec-0.3.pdf&sa=D&sntz=1&usg=AFQjCNHweO80ya5im6JaRqKv2ZzmZevh8w> > > > 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. That said, it looks interesting, I did not realize Qubes has something akin to a user manual. -- 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/8629a543-d18e-491e-9b02-123ce9fb4a72%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
