On Saturday, July 2, 2016 at 3:09:59 AM UTC-4, Duncan Guthrie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 01/07/16 18:19, raahe...@gmail.com wrote: > > On Friday, July 1, 2016 at 7:47:11 AM UTC-4, Duncan Guthrie wrote: > > > > > > On 01/07/16 02:05, raahe...@gmail.com wrote: > >>>> On Thursday, June 30, 2016 at 8:49:16 PM UTC-4, Duncan > >>>> Guthrie wrote: On 01/07/16 00:03, Marek Marczykowski-Górecki > >>>> wrote: > >>>>>>> On Thu, Jun 30, 2016 at 10:57:42PM +0100, Duncan > >>>>>>> Guthrie wrote: > >>>>>>>> Dear Qubes Users, I have been using Qubes OS for a > >>>>>>>> couple of days now. I own a Lenovo Thinkpad X200 and > >>>>>>>> everything works fine, including WiFi. However, I am > >>>>>>>> concerned about this, because my X200 has an Intel > >>>>>>>> WiFi chipset, which I know uses proprietary firmware. > >>>>>>>> I am concerned about this because the firmware could > >>>>>>>> be malicious, so I think this is quite bad from a > >>>>>>>> security perspective. The more proprietary software, > >>>>>>>> the worse security you have, as has been shown many > >>>>>>>> times. Since the hardware is secret, it is possible > >>>>>>>> that the WiFi chipset could be used to do malicious > >>>>>>>> actions without any way to tell. I am especially > >>>>>>>> concerned about the firmware being in dom0, which has > >>>>>>>> access to the hardware. > >>>>>>> > >>>>>>> WiFi card is assigned to NetVM and have no access to > >>>>>>> dom0. So even if its firmware is malicious, it > >>>>>>> shouldn't be a big problem. It may at most mess with > >>>>>>> your network traffic - which should be encrypted anyway > >>>>>>> for anything sensitive. > >>>>>>> > >>>>>>> In practice the only firmware still needed in dom0, is > >>>>>>> the one for GPU (if applicable). > >>>>>>> > >>>> I think this is a good idea in general, whether the firmware > >>>> is free software or proprietary software. However, there are > >>>> certain wireless chipsets (made by Atheros corporation) which > >>>> work without a proprietary firmware blob for WiFi, but don't > >>>> for Bluetooth, so even if they largely work without the > >>>> proprietary program, the operating system still loads some > >>>> proprietary program not needed (most people don't use > >>>> Bluetooth at any rate). I own such a chipset on my desktop > >>>> computer; Debian works without any proprietary software at > >>>> all, while Tails loads firmware for the Bluetooth. What is > >>>> the answer to this, do you make exceptions for firmware only > >>>> for wireless cards and GPUs? Or do you just allow them all > >>>> through. > >>>> > >>>> Another thing I have read is that Linux-libre's deblob > >>>> scripts don't just get rid of firmware that is proprietary, > >>>> it removes all binary files disguised as source files (e.g. > >>>> some binary file named "something.h") and "obfuscated" driver > >>>> sources (I believe that the 2D nv driver has been accused of > >>>> this). Would you consider at least adapting the deblob > >>>> scripts from Linux-libre to work for your kernel to only > >>>> allow select firmware through, for the most common computers? > >>>> Another option, like Debian (and, if I recall, Ubuntu to some > >>>> extent, although I have never installed Ubuntu), which I > >>>> think would be even better is to have a completely free > >>>> kernel by default, then a separate repository for firmware, > >>>> which can be enabled in the installation process. It would > >>>> probably be considerably simpler than adapting the deblob > >>>> scripts to be quite selective, too. It wouldn't make Qubes > >>>> compliant with the Free Software Foundation's "Free Software > >>>> Distribution Guidelines", but I think that from a security > >>>> perspective it is better than including the proprietary > >>>> 'blobs' by default, and is a balance between usability of > >>>> obscure hardware and security of dom0 (it never hurts). What > >>>> do you think of this proposal? > >>>> > >>>> ---- Thanks for your reply, it was really helpful for > >>>> allowing me to understand more about your security policies. > >>>> > >>>> D. > >>>> > >>>> > >>>> > >>>> I think what Marek is saying is that from a security > >>>> standpoint it doesn't really matter because the netcard is > >>>> isolated even at the hardware level with iommu supported > >>>> system. And if it messes with your network traffic you > >>>> should be using encryption, https or tor etc.. > >>>> > >>>> I think the reason they are not adopting such kernel is cause > >>>> qubes is trying to get more users and hardware compatibility > >>>> is the biggest hurdle and turn off to people. Its still new > >>>> type of os and people are hesitant. Also most people use > >>>> laptops and wouldn't be as willing to buy an external usb > >>>> network card for qubes. Which might also be troublesome in > >>>> some cases when trying to isolate usb controllers. > >>>> > > I understand what Marek is saying. I'm saying that ideally we > > shouldn't let any proprietary software by loaded by dom0, because > > we simply have no idea what it does. For example, someone could > > pressure the people who write the firmware to put something nasty > > in it designed to attack Qubes and TAILS users, to exploit Xen and > > break out of the hypervisor. It is a distinct possibility, > > considering we are living in the age of Orwell. What I am proposing > > (nonfree repository turned off by default) means that we can have > > hardware support while ideally avoiding the proprietary software as > > much as possible. If it works for Debian and Ubuntu, then I am sure > > it would work for Qubes. For instance, this might be easier if dom0 > > was based on Debian, as I am aware this was discussed. > > > > I am also still confused about how I might install Linux-libre in > > dom0 and replace all the proprietary stuff with the packages from > > freed-ora repositories (or my own). I think a guide in the > > documentation for this would be good. Does anyone have any ideas? > > > > Thanks for your reply, D. > > > > Ubuntu and Debian don't do that. So i'm confused by your > > statement. They have repos, on by default, for proprietary > > firmwares. That is something trisquel does which 100% libre. not > > debian or ubuntu, imo. > > > > I used trisquel for a while and loved it. Loved how it was very > > light and everything could be accounted for easily in the logs, and > > it prevented me from accidentally installing some binary blob. It > > was my distro of choice for compiling grsec kernel because it > > required no tweaks to anything, unlike any other distro. But > > eventually I had a need for some proprietary firmware and switched > > to debian on my baremetal machine. > > > > And like ALex says, even if not it doesn't mean that you should > > then totally trust your free firmware. You are just as much at > > risk as anything else imo. You still have to trust the people > > writing it, unless you are reviewing the firmware yourself. Sure > > bugs will be fixed quicker hopefully, but you should still consider > > it a security vulnerability that can be targeted. > > > > Maybe a libre kernel could be an option, I see nothing wrong with > > that. But to take away the freedom of people who want to use > > proprietary firmware for certain devices is probably not something > > Qubes is gonna do. They are trying to reach wider audience to get > > adopted by more people at this point and hardware challenges can be > > a problem. I for one would never want to run proprietary firmware > > on my qubes machine, and maybe eventually qubes can afford to take > > such measures to prevent them, but I definitely wouldn't advise > > that now. > > > > > I know that Debian, in the default install, only enables 'main' if you > require no firmware. The installer does not include the proprietary > firmware; you have to insert it on removable media. The repositories > are separated: main -free software only, contrib -free software that > requires or enables proprietary software in some way, nonfree -nonfree > software. Ubuntu has restricted which is the same thing although this > is enabled automatically in many cases (although you have to make a > conscious effort to turn it off). That is what I am proposing. I don't > know what you all think. > > Now, coming back to my original question: how can I install > Linux-libre? What Qubes-specific patches are there to the kernel? > Would I be have to rebuild it and apply the deblob patches, or is > Qubes considering providing it in the repositories? > > Thanks for all your correspondence, > D. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXd2hvAAoJEPs8tiiQ8FTA+b0QAJGIiehefQTZqcI4w/yZhXty > HDn08+lsRUaNLA44YVsj6rHbJ30jvut/8DgKWw4RFVicMJPSKzYjzdtPpVtTWgSk > YFeGFM0gus7pYvnzyL1LcjiHhnkO1nEz7wUAAu9FgaTHhy6ZFPR2egsls6s8l3gL > mndCrdmyTkmrl++ewrF3i22lgYzMJvbWaC1fS9DfufjhXTTVMy5NvB4oY8fd+52o > 7hE4kkRRfOtyknHUz9LIRO9ddl81mrjjh7k8Khwa/Nm+1EQoHZ+5Lc5hyulDqlBE > bF1b7LroiAa+JEf5geU9bwZfC3q16UOCEd7Ci1EoCk6yiyGeCpI/iSXS6gjNANNM > ulI9m3t81qAR1w8kIin+h1B2sGa17xdFmZecfkEGhkfKUfpCgbowvOOjuIOPMKcj > vpM5VDNjsrK/9eAaPKm4acbhncz6S8B8TtQsBXqBIVUYE2wLCZo/8qgEgAiJ7Rpr > 6yoPT5Yn+1w1+4dIaHNBQX28ZjfSCRaf66KZ32pSW5YBbOCANPViiDuvLVLgBb5e > Uh94GomY91nv0Ec49vXuqT7FP5Q3TpW+0RR4qbNO7oo83YMGG49DsjqYp4hyF+f4 > e7b/08fY9ZlBEBRFqwjgAzTyJp8p/Ni/z4VqbBckEgdQsWNM3Mz1l4FpAVDi9L6a > TwWkNCneIz8dOYQQxK9Y > =0GO4 > -----END PGP SIGNATURE-----
well compared to trisquel, on ubuntu and debian you won't have to buy a usb dongle to get a wireless connection. And you won't have to add any additional repos. As far as linux libre, I'm not sure about dom0. Someone else probably knows. But you should be able to install it for template vm. -- 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/75ac2709-ace9-4710-bae6-65a9a6daa8b9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
