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' -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d5aa8d5b-7171-467c-badd-8098db2188c4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
