Hi Chris,

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.

1. Dec 2016 21:03 by tas...@openmailbox.org:


> On 12/01/2016 03:03 PM, entr0py wrote:
>> hopefulf...@tuta.io>> :
>>> Hello,
>>>
>>> Currently any AppVM has persistent storage, it is referenced by
>>> default at least as /home, /rw/config, /usr/local. And software is
>>> executed from this persistent storage from read-only system.
>>>
>> There may be additional persistent storage enabled as well[1].
>>
>>
>>> This allows an adversary to install persistent AppVM exploit e.g. via
>>> ~/.bashrc or /rw/config/rc.local. Advanced exploit can then hide its
>>> own invocation script, so it won't be possible to detect it from
>>> running VM itself (at least aafter /rw/config/rc.local is executed;
>>> so better check when VM is turned off).
>>>
>> Hence, all untrusted activity should be performed in a disposableVM or 
>> untrustedVMs with nothing of value.
>
> There are more threats from persistent malware than what has been discussed 
> so far. As one example, the lax security within appVMs makes them an ideal 
> target for launching attacks against other computers on a network. Another 
> example is when long-term profiling of a victim's system is required before 
> launching an attack.




Good threats to consider!

 


>
>
> If normal permission-based security is enabled in an appVM/domU, then there 
> is a chance that system updates can render malware installations defunct. 
> Actually, the chance of this working is much better on Qubes because no 
> private.img-based rootkit can attempt to corrupt the update process. So one 
> of Qubes' best features is partially negated by default; Malware that got 
> into the VM via an application vulnerability can easily persist as a kind of 
> rootkit by simply adding a 'sudo ...' command to a user script.
>
>
> The first step in addressing the issue is to follow the 'vm sudo' doc 
> (disregarding the outdated explanatory part)...
>
> https://www.qubes-os.org/doc/vm-sudo
>
> I think given recent developments in computer security, re-enabling guest OS 
> security will improve overall security on Qubes.
>
> Chris




IMO, restoring user and root users in the VMs won't help with preventing 
persistent exploits - only removing the persistent storage will (and taking 
measures to prevent code execution from it, be it preserved in some VMs like 
Whonix-Gateway). 








Hopeful Fork


 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/KXwbXhS--3-0%40tuta.io.
For more options, visit https://groups.google.com/d/optout.

Reply via email to