Application firewall

General Discussion
41

I think running anything in dom0 is a bad idea, but i’ll check tripwire/AIDE and see if and how I can use any (in a way that definitely doesn’t involve dom0)

1 Like
42

Suggestion: IDE in sys-net & sys-firewall to “ensure” (as good as possible with the current state of things) non-malicious traffic.

43

@redmind wrote:

I think running anything in dom0 is a bad idea…

Since there is no networking in dom0, any bugs discovered in dom0 desktop components (e.g., the window manager) are unlikely to pose a problem for Qubes, since none of the third-party software running in dom0 is accessible from VMs or the network in any way. Nonetheless, since software running in dom0 can potentially exercise full control over the system, it is important to install only trusted software in dom0.

Not running anything in dom0 is not really an option, so I suppose you mean installing and then running additional software beyond what Qubes OS puts there during a standard install.

For novice users it certainly is not a good idea to install and subsequently run anything in dom0. However, when we are discussing tripwire, AIDE, and other intrusion detection software it is safe to say we are talking about advanced users.

Such an advanced user might see that the Qubes OS project already must trust the Fedora repository as that’s where the majority of packages in dom0 are pulled from. Further one could then argue that certain tools like redshift, devilspie2, tripwire, or aide are well-known tools provided through the Fedora repositories and installable via qubes-dom0-update as described on the page linked above and not really any different from a trust-perspective then say XFCE components.

Obviously it is advisable to do any learning / experimenting inside a qube and only apply to dom0 when fully understanding what and how is being done.

44

My take is that you’d want to use the disaggregation approach and run “proxy” VMs between your appVM and whatever network connection they usually have. Potentially have a logging vm pull data directly from the proxy VMs for a centralized view.

[The Qubes API is moving in the direction of allowing domUs to be given control over other domUs based on policy settings in dom0, negating any need for custom software in dom0.]