Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upNetwork is a single point of failure #1005
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Take a look at #806 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
May 22, 2015
Member
Also it applies only to networked VMs. You can have offline VMs - for example gpg backend.
|
Also it applies only to networked VMs. You can have offline VMs - for example gpg backend. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
v6ak
May 22, 2015
I must have overlooked the issue you are referencing :-(
Yes, it applies only for network connected VMs, but this still includes sys-firewall and subsequently also any TemplateVM, so it also consequently affects all non-standalone VMs, even if they have no network connection.
v6ak
commented
May 22, 2015
|
I must have overlooked the issue you are referencing :-( Yes, it applies only for network connected VMs, but this still includes sys-firewall and subsequently also any TemplateVM, so it also consequently affects all non-standalone VMs, even if they have no network connection. |
v6ak commentedMay 22, 2015
Imagine a vulnerability in Linux kernel networking stack that allows remote code execution. Qubes is in many setups almost unprotected against such vulnerability, as attacks might be cascaded from sys-net to all other VMs.
Although this is non-trivial, I suggest running some BSD OS in NetVM, that would diversify the ecosystem and thus make such attacks harder.