On Saturday, November 11, 2017 at 8:25:37 PM UTC, Jean-Philippe Ouellet wrote: > > On Fri, Nov 10, 2017 at 4:44 PM, Yuraeitha <yura...@gmail.com > <javascript:>> 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 <yura...@gmail.com> 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 <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. > >> > > >> > > >> > > >> > 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 :) >
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 :) -- 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/46cd2f16-8437-44c8-8151-d8c51e0b1766%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
