What's the future of QubesOS Default Security Configuration?

[BEBF738VD]

@gehekal580

What worries me the most is the default security configuration - profile shipped by the default QubesOS ISO which provides an interesting surface for various exploits.

@gehekal580

All of this could be fixed but what about the typical QubesOS end-user that do not have the necessary skills to handle this?

Every user’s needs are different, so it makes sense to ship, for example, the default Firefox configuration. If you think something is truly unsafe, you should report it to the upstream developers of the respective packages.

In the meanwhile, if you wish to harden firefox, you should check out my guide: [Guide] Automatically install extensions and configure new (dispvm) hardened Firefox profiles with arkenfox user.js and policies

Or harden your VMs with kicksecure: Hardware information masking and spoofing with hypervisor - #5 by BEBF738VD

@gehekal580

is the end user condemn to reduce the security risks on his own, modify and patch the entire system on day-to day basis?

Using Qubes OS instead of any other OS is arguably already a big security improvement.

@gehekal580

Would it then make more sense to limit the capability list (permissions) to all untrusted domains? And why does the “user” in the untrusted app - vm even have the capability to perform sudo operations? I’m not arguing why we use Passwordless root, my question is why do we need sudo to browse web in the first place?

You can create minimal templates which, by default, do not include the qubes-core-agent-passwordless-root package.

@gehekal580

Finally, if an attacker could in fact exploit the untrusted vm trough a buggy browser, what’s really there to stop him from doing the same to any other qube including dom0?

An attacker should exploit a Xen vulnerability.