On Friday, July 1, 2016 at 7:47:11 AM UTC-4, Duncan Guthrie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > 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. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXdlgOAAoJEPs8tiiQ8FTA8MEP/A+Y2AjpMVNVFb6wMAKnZxd5 > rSBhdXxBL6Evfz5jq3J+a2ApOkmv/GCaZ2rn7V+tcu7mEs2Uwd8vEaoD9PJSZA2Z > bwiGis8be3ysK7eBSUa0OUCkYF7GMN7H0T1nVrL5GtYqbAODq8MOe0fWnPKTUU0h > 3C7c5ffXpFxhxPS9/IbMnBisnNbr55hxAcSbklY0Wjl/6b7URp10tPpkyN3RW7zi > u+HgCdi9MQXotTbzCr7KCPwJ1G3U/5aC1+uaSKZKQAGcRNTKEDuupwBEce2VcdpV > wIIF6oqSSXUbK9m73+hE/i/meTq+66Hm8yv6fNHNZbtulpngMrqTKjpnOZOzLmO6 > ZPTXcj6Tcjj1AaZ89Ym06wtQTgmCI90LVV/A8xx6X0euELILBc0NSp2vLNR4tdkJ > Czvh6+fp65Q+qC8u48QeiIajqtW7XDbrUkgGHX0kVEVnxJ9aVu43TOEe4kYd+P/t > JBZqlnIS2fIb8594OQnBc+ivqees4/nBZLbBlfLYrK+btHnvvzEHdm6jI/bFvkqX > 1kKGox5z5h+WwgLYKEC7OnrWQZ9pt8eianUrs9388Lsc6aW6q/26svdik3yFP6Mh > Rn0Too0GumOPI9+KV7Cu0BO5cSMfQkeFnjCaw+TeBT3qvYhEqlQ0mz5pSB15w53p > 4HzeUKZAwW+NdYnGYRbq > =n4PG > -----END PGP SIGNATURE-----
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. -- 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/266337f1-ffd9-4dec-8c26-13930a5d5ce2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
