Restoring Dom0 networking + mitigating drawbacks + compiling a program from source in Dom0
117 views
Skip to first unread message
daltong defourne
Jun 2, 2016, 11:54:59 AM6/2/16
to qubes-users
Hello!
First and foremost, I did google and I did read this thread about Dom0 not being networkable anymore
https://groups.google.com/d/msg/qubes-users/c2RyhLmTCm4/VQXWnHtyBQAJ
However, I need to have 3d acceleration available to a trusted-ish (in the sense, developed in-house) program that would need network access.
Performance w/o acceleration access is unacceptable, while accelerated performance is okay (tested on raw fedora) so just giving up and running it in a Qubes AppVM is sadly not an option
The software also needs network access.
Current plan is to
1) restore Dom0 networking via netvm
2) build the program inside Dom0
3) take additional steps to mitigate possible risks (maybe run it in something like firejail - software in question runs well inside firejail in isolated network namespace as non-root with firejail's secomp and caps filters enabled)
Thus questions are:
a) how do I restore Dom0 networking via netvm "properly"?
b) are there any additional pitfalls to compiling stuff in Dom0
c) what mitigations beyond firejail would be prudent (maybe also run something like pdnsd in netvm to deal with DNS-related issues mentioned here specifically?)
d) is this entire undertaking a worse idea than "just run this "trusted-ish" thing on an arch linux machine with grsec and a few KVM VM's for isolating less trusted apps" ?
Thank you!
First and foremost, I did google and I did read this thread about Dom0 not being networkable anymore
https://groups.google.com/d/msg/qubes-users/c2RyhLmTCm4/VQXWnHtyBQAJ
However, I need to have 3d acceleration available to a trusted-ish (in the sense, developed in-house) program that would need network access.
Performance w/o acceleration access is unacceptable, while accelerated performance is okay (tested on raw fedora) so just giving up and running it in a Qubes AppVM is sadly not an option
The software also needs network access.
Current plan is to
1) restore Dom0 networking via netvm
2) build the program inside Dom0
3) take additional steps to mitigate possible risks (maybe run it in something like firejail - software in question runs well inside firejail in isolated network namespace as non-root with firejail's secomp and caps filters enabled)
Thus questions are:
a) how do I restore Dom0 networking via netvm "properly"?
b) are there any additional pitfalls to compiling stuff in Dom0
c) what mitigations beyond firejail would be prudent (maybe also run something like pdnsd in netvm to deal with DNS-related issues mentioned here specifically?)
d) is this entire undertaking a worse idea than "just run this "trusted-ish" thing on an arch linux machine with grsec and a few KVM VM's for isolating less trusted apps" ?
Thank you!
Marek Marczykowski-Górecki
Jun 2, 2016, 8:20:25 PM6/2/16
to daltong defourne, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, Jun 02, 2016 at 08:54:59AM -0700, daltong defourne wrote:
> Hello!
> First and foremost, I did google and I did read this thread about Dom0 not
> being networkable anymore
> https://groups.google.com/d/msg/qubes-users/c2RyhLmTCm4/VQXWnHtyBQAJ
>
> However, I need to have 3d acceleration available to a trusted-ish (in the
> sense, developed in-house) program that would need network access.
>
> Performance w/o acceleration access is unacceptable, while accelerated
> performance is okay (tested on raw fedora) so just giving up and running it
> in a Qubes AppVM is sadly not an option
>
> The software also needs network access.
Instead of breaking Qubes OS, better dualboot to some non-Qubes
distribution for this application usage. It will be significantly more
secure than exposing dom0 to network access. And even if that second
system would be compromised, will not be able to _directly_ steal your
data, as Qubes OS partition is encrypted by default. But while running
on bare metal, will be able to infect your hardware (think of BIOS, all
the firmwares etc). Usage of Anti-Evil-Maid is advised here to at least
detect some of those attacks.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXUM1BAAoJENuP0xzK19cs/LgH/RnMYLXsw3Vk4b10tM/xDI/q
C+0X9+otlYK6gUm3FiWGW/xiwuooJPCglF0L2FOuy/A7FFhyBYTbH/nskZsJTmQZ
mE5lR6SLTth+6EIv93EDQxkUOWbHY2jN7N9uYITSPOP4mytKhSJ19A6WhbL4PNmh
h2lF1XHqZV6w1MXmijXJtql179b8+dff4vsADEnZFx/dLAWLtosLAFJ6AnSmELWf
dkHtPnViClGjbSmoIRmUiUbcbwXmG4GndVsod1nAE5DQ8VDceZkFlE03wQm3LlaG
Y6+UxsJ/FXGxhwDqVL6lQjF6jhPPiwwyv4b2LjcQWIU7Hs2iBoLZXQSRLsGocr0=
=YjjE
-----END PGP SIGNATURE-----
Hash: SHA256
On Thu, Jun 02, 2016 at 08:54:59AM -0700, daltong defourne wrote:
> Hello!
> First and foremost, I did google and I did read this thread about Dom0 not
> being networkable anymore
> https://groups.google.com/d/msg/qubes-users/c2RyhLmTCm4/VQXWnHtyBQAJ
>
> However, I need to have 3d acceleration available to a trusted-ish (in the
> sense, developed in-house) program that would need network access.
>
> Performance w/o acceleration access is unacceptable, while accelerated
> performance is okay (tested on raw fedora) so just giving up and running it
> in a Qubes AppVM is sadly not an option
>
> The software also needs network access.
distribution for this application usage. It will be significantly more
secure than exposing dom0 to network access. And even if that second
system would be compromised, will not be able to _directly_ steal your
data, as Qubes OS partition is encrypted by default. But while running
on bare metal, will be able to infect your hardware (think of BIOS, all
the firmwares etc). Usage of Anti-Evil-Maid is advised here to at least
detect some of those attacks.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXUM1BAAoJENuP0xzK19cs/LgH/RnMYLXsw3Vk4b10tM/xDI/q
C+0X9+otlYK6gUm3FiWGW/xiwuooJPCglF0L2FOuy/A7FFhyBYTbH/nskZsJTmQZ
mE5lR6SLTth+6EIv93EDQxkUOWbHY2jN7N9uYITSPOP4mytKhSJ19A6WhbL4PNmh
h2lF1XHqZV6w1MXmijXJtql179b8+dff4vsADEnZFx/dLAWLtosLAFJ6AnSmELWf
dkHtPnViClGjbSmoIRmUiUbcbwXmG4GndVsod1nAE5DQ8VDceZkFlE03wQm3LlaG
Y6+UxsJ/FXGxhwDqVL6lQjF6jhPPiwwyv4b2LjcQWIU7Hs2iBoLZXQSRLsGocr0=
=YjjE
-----END PGP SIGNATURE-----
Vít Šesták
Jun 3, 2016, 3:44:52 PM6/3/16
to qubes-users
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'
* 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'
daltong defourne
Jun 3, 2016, 5:35:47 PM6/3/16
to qubes-users
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
Marek Marczykowski-Górecki
Jun 4, 2016, 1:44:55 PM6/4/16
to daltong defourne, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Fri, Jun 03, 2016 at 02:35:47PM -0700, daltong defourne wrote:
> 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
It worth evaluation, but sadly we don't have resources for that. Having
> 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
it in Qubes require a lot of work:
- evaluate whether it is usable in Qubes at all (for example whether it
doesn't give every VM full access to the screen content etc)
- evaluate whether it works with qemu in stubdomain (and without one in
dom0)
- integrate with Qubes setup (especially adjust/replace gui-agent to
make use of it), adjust stubdomain build etc
- decide (and implement) a way to enable it (I guess the initial
evaluation would result in at least "don't enable by default as it
greatly enlarge attack surface")
And probably some more.
But if someone from the community could help us with this, we'd be
really grateful.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
1RGwuqTNAN9waPY0Jx+lMApLoY8wqjTEhMl/PT4ECpy7nby1wYLatzyXpiOkMql5
iAlVmQCKLeFtmK2IwjiBY5NuB5g1DpbqtVbxsp1jzbYxRcBHdGKIiVYUww0zo/Od
YPbbvzYlI9EOQTsA7tPec332a0vy9cpwBQzfZJpquGBqWtjdD2ZbA2Uig1b25bsM
OIG7FtUcUMcBSpbp1CO16AF4MH+dkGGI6QoCqXExGHbiIWJ4tjgMla5N9YZ6CSuY
Dqr3yRIPKvfY91yYpUWnmFAYYfwW7l76FuYNF8Owzw/SboT4HluS94Q4gYOSgJY=
=rGTP
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages