-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/07/16 18:19, [email protected] wrote: > On Friday, July 1, 2016 at 7:47:11 AM UTC-4, Duncan Guthrie wrote: > > > On 01/07/16 02:05, [email protected] 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----- -- 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 [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-users/ac16bae0-60d0-783f-4578-f2d59d5be34c%40posteo.net. For more options, visit https://groups.google.com/d/optout.
