-----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----- -- 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/64407fea-b439-7774-ca92-3e529756bc94%40posteo.net. For more options, visit https://groups.google.com/d/optout.
