On 12/01/2016 06:00 PM, hopefulf...@tuta.io wrote:
I agree with you. It is strange to me that Qubes doesn't follow
defense in depth principle when thinking like "this vm is untrusted so
we won't even try securing it". Sure, the vault vm won't be
compromised - but that isn't the only asset to defend.
I would like to clarify on this point:
"Defense in depth" per se is a philosophy that is outside the scope of
Qubes and could even threaten the Qubes philosophy and reason for
existing. Much of DiD strikes me as wild-goose chasing (and posturing)
when it is pursued by users and admins. Qubes Project should not spend
any significant time or resources on DiD even while not preventing it in
However, traditional guest OSes like Linux and Windows do have their own
internal *default* security schemes (which form the basis for DiD) and
they often do impede various types of malware at least on a case-by-case
basis. Qubes should allow regular guest security to play their role in
(hopefully) impeding malware and making Qubes VMs less desirable targets.
Even though reports of in-the-wild exploits against Qubes are
exceedingly rare, Xen security did not turn out as good in practice as
it was hoped. So there is a short-term remedy and a long-term one as I
see it: First, re-enable guest security by default, then stimulate
interest either in finding a better hypervisor/microkernel (unlikely) or
in putting Xen and its development process under a stronger microscope
(more realistic). (Another long-term goal to enhance security would be
to get Qubes off of x86 and onto a hardware platform specified by the
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.