On Thursday, June 30, 2016 at 8:49:16 PM UTC-4, Duncan Guthrie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJXdb3qAAoJEPs8tiiQ8FTAf4wQALdWB123VGv9OdisLfI2OQda > 6r6IyVWPny+shAuoxfiui+0HmkHZB8CMaAleLGmyOo+iWT8jBiTbqV8qMTfWO9kL > My1TUuvEB12s7RGecqKxRlz5ij1cmnpbCg2yXM1qfEpFLYtw9d9agw4fEiSOCokY > aF7nuPeLXZjp91mSaTRRV/U4JXd09XFU1/dULNUv+0Pmr7uT+8ZhlLdGHaRoN2SV > +AmgVQdtnRoIsJWRrEeT9CG6KS5Z7+JmGNcOfVIW9CSa2WFG+JFbiJEyfo26IciP > ofAMzqapBWZwzlxJ6pNriGgacYeyHKMJwBK34RCebuyrpreLU5QutxZ3avO9yoHh > JUqNdffcwlL43noZ89i9SIV+wYcB9Nj9PvUjPzCuxXMfFHkaNJ4cI17N/mLZzKXc > 0SCKn5DAFjOz2wBQ/M4KTYoBfPbj0HWkBlbNdHNYzIutfMWG5NbMkIbph46tjWkF > yThTSZZoCLChhZ0OAnEc7vNLCcwCVArXo6P0L+FDdAMDTVLxk8CaFOuhIWFQXnG1 > Q20K3sTlTh2pPjf2bvEXNlFOBQ2H7tHV4YVyyoqsEsFyr3aq4KiEUcffhWma6Y8H > 5XT405xg80/17L2sHYJciE+k6U9C1tpJe2BYYnOWrId3E72gL+AGpnB3h9J/6s/g > tvxD9xDk5VSpnb13dnJb > =WZ6b > -----END PGP SIGNATURE-----
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. -- 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/2aa1de42-184c-4308-9081-16b555ab1c9e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
