On Friday, June 3, 2016 at 10:44:52 PM UTC+3, Vít Šesták wrote:
>
> If you really want to run such app in dom0 (and the alternative proposed 
> by Marek is not good for you), I suggest the following: 
>
> * Use something like netcat in some network-enabled VM, call it from dom0 
> by qvm-run and use pipes. This brings limited networking capabilities to 
> dom0, without taking risks like the glibc DNS vulnerability. 
> * Make the communication authenticated and maybe also encrypted. This can 
> be done another in the AppVM that provides network access (e.g. by using 
> openssl instead of netcat) or in dom0. 
> * The code that parses input is security-critical, so it has to be written 
> accordingly. 
> * All libraries that are in touch with untrusted input (maybe openssl and 
> some parsing libraries) should have all relevant security updates. This 
> might be an issue with shared libraries, because they are rather outdated 
> in dom0. You can link proper versions statically or try compile up-to-date 
> versions of such libraries for dom0. 
>
> Both approaches (my approach and Marek's approach) have some advantages 
> and disadvantages. Marek's approach seems to be easier to implement, but it 
> does not allow running parallel with other VMs. They also differ in ways of 
> mitigating attacks. Marek's approach relies on proper usage of AEM and on 
> BIOS and firmware based attacks being out of attacker's scope (or on being 
> such attacks mitigated by signatures checked by hardware). My approach 
> relies on isolation of networking and limiting attack surface of dom0, but 
> once your application is owned, it is essentially a game over. 
>
> Regards, 
> Vít Šesták 'v6ak'


Thanks Vít and  Marek!

Looks like messing with Dom0 is a terrible can of worms.

I guess I'll look into running stuff on a (relatively hardish) distro, 
perhaps with some more "vanilla" isolation done for suspicious apps 
(dualbooting Q is of course an option, but I suspect >50% of intended users 
will find it unacceptable)

Sad I won't be able to use Qubes for this project cause, frankly, I found 
Qubes ergonomics, usability, and security properties very attractive.

P.S.:
By the way, is anyone looking at leveraging XenGT (I know it was discussed 
some time ago at the dev list, but those messages are old, and XenGT 
project seems to be still alive and kicking 
https://www.phoronix.com/scan.php?page=news_item&px=Intel-2016-XenGT-KVMGT 
) ?

Because I'd gladly migrate to Qubes as soon as 3d acceleration in its VMs 
becomes a thing
 
 

-- 
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/0b454819-ad08-41f9-aa6e-fd95b96a980f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to