[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska
Raspberry Pi as a DVM is not that easy, but it is probably possible: 1. Let's have an image for the "VM" in your laptop. 2. Insert a SD card to the laptop and dd the image. 3. Boot Raspberry Pi. This assumes that: * You perform this every time you want a clean state. * Raspberry Pi has no persistent storage outside of the SD card. * MicroSD card cannot be hacked (e.g., Raspberry Pi cannot overwrite the firmware). * Your laptop is not configured to parse anything from the card. (If it is not that case, it could try to compromise your laptop.) Regards, Vít Šesták 'v6ak' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8286b8c8-4b3c-4980-88a0-7bc77d87be83%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska
On Tuesday, January 23, 2018 at 11:30:08 PM UTC-5, Syd Brisby wrote: > some considerations: > > * Raspberry Pi, beagleboard, USB armory, etc are very low-powered devices (in > both CPU & RAM). So running Qubes software on them at a productive speed will > be a challenge. > > * You're saying that laptop hardware specs are a problem for users. But > remember we had the problem of wireless modules still broadcasting after > being turned "off". So we needed laptops with wireless hardware switches to > be more certain that we couldn't be hacked. But now you are asking us to > again trust ordinary laptops and tablets that may not have hardware switches. > > * In reality, you are also changing from "deployment and virtualization" as a > single point of failure to "wireless" as the single point of failure. For > example, WPA2 has been declared insecure (hackable), with WPA3 being > necessary as a replacement. But, amazingly, WPA2 is still being "patched" by > manufacturers who think it's still acceptable - so how long will it take for > WPA3 to become ubiquitous? Not sure how WIFI own encryption would be a single point failure, be it WPA2 or not, which I fully agree was a mess from the start. Is it not one a fair number of reasons we all use some combo of HTTPS VPN SSH TOR etc? Would anyone here connect to the net without such a combo even just to surf regardless of the inherent black box network security? Regardless of the connection medium be it radio waves via wifi bluetooth a network patch cable would it really matter? At my house I use a pi as a radius server so I am quite happy I got my patches for the wpa and not just sitting for 8 months waiting to get a unproven wpa3 rolled out. Not to mention that if wifi upgrades match android it will take 5-7 years before unsupported code is no longer in wide spread use. (I also use separate networks for things like TV IOT etc and data I consider higher value.) Back on the subject of Qubes Air: I could see connecting to a Raspberry cube or USB Armory Qube etc in a separate Zone via coms thru a VPN proxy VM qube connection. I think this works to handle the above stated PDF scenario or as even a way as a further isolation from a badusb infected drive containing files. I can also see it being a way to expand it into a decentrailized network of managed qubes with differing levels of security much like our current single PC Qubes OS presently offers. Qubes has to be removed from any specific platform such as X86 or even the hypervisor unless we will always be at the mercy of their security practices etc.. Best not to be permanently married but rather a dating relationship. The key would be ensuring one zone could not compromise another zone if proper workflow security practices are enforced/followed. Much how we handle data transfers between domains/qubes of different trust/security levels i.e red vs black etc... IMO once a level is chosen it would nice if rules could be enforced to prevent data flow rather than relying on the user to remember the proper flow. IMO this becomes a priority with increased domains zones qubes etc.. That data can only flow in the proper direction without explicit work. Its critical to understand that what the qubes OS is today would not be what would necessarily be running on these other zones but it also does not dismiss them from running it either. You have to remove the idea of being what the entire QUBES OS we have today . Anyways I liked the thought process and vision of the writeup. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6702b77f-10cc-4d8b-b76a-fb2fa486f16a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska
On Wednesday, 24 January 2018 04:30:08 UTC, Syd Brisby wrote: > some considerations: > > * Raspberry Pi, beagleboard, USB armory, etc are very low-powered devices (in > both CPU & RAM). So running Qubes software on them at a productive speed will > be a challenge. Perfectly fine as a USB decryptionVM or as a Split PGP with the benefit of not have your keys in CPU cache. > > * You're saying that laptop hardware specs are a problem for users. But > remember we had the problem of wireless modules still broadcasting after > being turned "off". So we needed laptops with wireless hardware switches to > be more certain that we couldn't be hacked. But now you are asking us to > again trust ordinary laptops and tablets that may not have hardware switches. > > * In reality, you are also changing from "deployment and virtualization" as a > single point of failure to "wireless" as the single point of failure. For > example, WPA2 has been declared insecure (hackable), with WPA3 being > necessary as a replacement. But, amazingly, WPA2 is still being "patched" by > manufacturers who think it's still acceptable - so how long will it take for > WPA3 to become ubiquitous? On the Raspberry side, wireless is a no go. Secure wired connection will be required (to mitigate L2 and below attacks). On the laptop side, sys-net will mitigate L2 and lower attacks. so your GUI connect to your QubesAIR by connecting to sys-firewall... nothing is changing (with the assumption that the protocol for remoting between Qubes is secure). -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e467b8dd-f3c6-4633-b6c6-5bcc33bae388%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska
some considerations: * Raspberry Pi, beagleboard, USB armory, etc are very low-powered devices (in both CPU & RAM). So running Qubes software on them at a productive speed will be a challenge. * You're saying that laptop hardware specs are a problem for users. But remember we had the problem of wireless modules still broadcasting after being turned "off". So we needed laptops with wireless hardware switches to be more certain that we couldn't be hacked. But now you are asking us to again trust ordinary laptops and tablets that may not have hardware switches. * In reality, you are also changing from "deployment and virtualization" as a single point of failure to "wireless" as the single point of failure. For example, WPA2 has been declared insecure (hackable), with WPA3 being necessary as a replacement. But, amazingly, WPA2 is still being "patched" by manufacturers who think it's still acceptable - so how long will it take for WPA3 to become ubiquitous? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/14b5f8d3-8807-442c-8a88-9a2685ec4fde%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska
On Monday, 22 January 2018 15:35:47 UTC, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Qubes Community, > > Joanna Rutkowska has just published a new article titled "Qubes Air: > Generalizing the Qubes Architecture." The article is available both on > Joanna's blog: > > https://blog.invisiblethings.org/2018/01/22/qubes-air.html > > And on the Qubes website: > > https://www.qubes-os.org/news/2018/01/22/qubes-air/ > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpmBMEACgkQ203TvDlQ > MDC02A//Qjy5eAxiUSY6ZOlTQ6zDlilXtBTbSH4ig3Wa1DL9Jg3vHnR955LP9snP > 40ZEIIc+cACis25g61SySbzkZUHXKW1cqfQCv/mjQAApWlFxQexIhX5WpS/u8RKB > PhNdgQVH+JYPOQZCidFAdkeSnBM+XFyxflPaCE1j1zisnTliH/Lwdl6xxEVht4nb > XglIZZz6D6PEQIouvM3qdsqi9DUY7Nc6AC5cLsI5NbVAcYtIVILxiSlxAM2OM/SL > k7rIoLnFGmgdmMJl5pInzy/b/SJvNmy70HjKRfg5y+EP9Wm024WaZQStacWmSfWa > x//plXVY/AuRWycyEtWLEdIhWNw4ZBV2CGkw72IxIN2SmJ+IfDA4N0fO81WZBJxo > gdH4Y/fkKZyUJ1/cKfttwt6jU8AOx8MZwmoh1tMjZbXuVPOoGgqBR0aXPAzAUcE2 > 5IpviczQZ0Ng9ZHyITZthiUO08nyqqJS8AH9UU4e2uDDq53TCXQa8pNzqgWtipY7 > BkGwNY+PZaf3dAfYgEyAh+IFnHRI6e38Ej0pysHSGM386B4n19tmhEf9zLjXc+oU > 2KUQJjOTp4ISfqNDYe3HpYsMR3RrqMWyMt3h4zG1gKPLhxAjAfdzVRq+Z0sBtJya > 2begkIa7u91kJlta2/T4N6E2bqpe9tdAzsy/StqRBnnjIsRjYlE= > =y84I > -END PGP SIGNATURE- As always fantastic article and work by your team. One point about the RDP security concerns... You could have (if 2 zones and 4 VM in each): 2x4x AppVM --> 2x4x CouldGUI+RDPd > 2x4x RDPc+DesktopGUI --> 1 QubesGUI --> local fast secure UI ---> compressed stream (RDP or other) You could possible have 2x RDPc+DesktopGUI (one per zone if this is your security/performance model). One point about Application as a service: I agree about browser isolation not being able to secure users (and certainly not able to manage privacy). Let's just ignore user isolation in Office265 ;-) Looking forward to what will come out. Devil is in the details. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/77558918-6b13-4c73-ad70-867511df8699%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
