Why don’t you get the Qubes Builder going and use grep?
You want to discuss details of the XEN version used in Qubes OS, yet the relatively simple task of finding out whether ‘the Xen version used by qubes’ is ‘compiled with it the XSM-FLASK module’ requires you to start yet another thread? Hm.
I’ll move this into the ‘hardening bin’ created for you.
Will try this; So I can deduce if XSM security modules have been compiled with Xen?
Well, I haven’t actually checked myself, but my expectation is that Xen gets compiled as part of the Qubes OS build process. Hence I expect you’ll be able to see the sources and how they are configured to be build.
I might do this myself tomorrow to follow along. Not sure there is a point to this inquiry but it seems worth it just to prove a point and for the experience.
The point, if I may, is to check whether or not the XSM-FLASK security module is available to QubesOS users and if they are able to create their own security policies similar to SELinux as described here:
https://wiki.xenproject.org/wiki/Securing_Xen
We’ve discussed securing various codebases outside of the hypervisor. But what about Xen itself? Both PV and HVM guests can attack Xen itself through the hypercall interface. While the Xen developers try to be very careful with the security of the hypercall interface, and now regularly do “fuzz testing” on it to discover potential vulnerabilities, it is inevitable that they will make some mistakes.
One of the ways to mitigate mistakes in the hypercall layer is to use the Xen Security Module (XSM) with FLASK. FLASK is a plugin for XSM written by the NSA, and is Xen’s analog of the SELinux security framework. It allows you to load policies to restrict what hypercalls a VM can try to make. Although this doesn’t guarantee that no vulnerabilities will be exposed, by restricting what hypercalls are valid, it reduces the probability of an exploitable vulnerability significantly.
FLASK is a mature piece of software, but writing policies is a very tricky and difficult task – not for the faint of heart. Xen does come with a useful set of “example” policies, which cover most roles that a typical installation would need to use; including driver domains, normal domains, stub domains, and so on. However, these example policies are not heavily tested; they should be used at your own risk.
The basic steps to use FLASK’s example policies are as follows:
seclabel=[$foo], based on their role.For more information, please see Xen_Security_Modules_:_XSM-FLASK
Maybe the opinions of the Qubes team have changed by now, but the founder was not a fan of XSM/Flask:
https://groups.google.com/g/qubes-devel/c/n7dKmUeBxzA/m/fZQJdX5WRGgJ
So the general conclusion is that it increases attack surface. We want less code, not more.
To the #5 in the list should be added, SSP - Stack Smash Protection, and newer mitigations like CFI (Control Flow Integrity) and ShadowStacks.
And I suppose a 6th point which includes deterministic(reproducible builds) for Xen and the dom0 OS.
And maybe porting Xen to Rust would also be a good idea.
This should fall under general discussion, FAQ, or, general hardening.
What compilers are being used to compile QubesOS for x86_64? GNU GCC? Clang?
Please STOP creating new threads for every thought that comes to your mind. If it has to do with hardening, please post into THIS thread.
Why don’t you check? I’ve previously pointed you to the Qubes Builder. I am not sure there can be one answer for all of Qubes OS. One would expect that the kernel parts use GCC. This thread seems to indicate that at least some parts are build with GCC.
Does Xen implement any of the security features used by Fedora as listed here?:
I really like your questions @huaopeng but I don’t think you’ll get any feedback worthwhile here. Maybe try asking some of them in the #qubes channel or maybe send a summary of questions as an email to qubes-devel?
Maybe state your purpose a bit more clear? Are you doing research? What’s your aim?
This forum is primarily a user community. While many here might be interested in the answers to your questions, very few will be qualified to provide any. That’s why you haven’t gotten that much feedback and I and others have tried to channel your inquires into one thread as to not overload the category with threads no one has an answer to.
Makes sense?
Yes just trying to modify Xen and QubesOS to specific use cases; it looks like that’s what MirageOS, OCaml and Opam are for.
Is the QubesOS #qubes IRC channel still active?
What about the application containerization that not only the VMName next to it, but also have the container ID with hexadecimal with random numbers of characters?
Are you suggesting a sort of functional package manager for Qubes templates and AppVMs? That sounds
similar to Nix where the package dependencies are explicitly defined and then hashed.
What I mean is that instead of this:
[sys-usb] Parole Media Player
just be like this:
[sys-usb] [C-5e3c9a9d4f4b88] Parole Media Player
Something similar to that, and if we open the same program in the same qubes, it would something look like this:
[sys-usb] [C-222fae668fbccd118] Parole Media Player
As a random container ID hash on the application window title.
Did you understand that?
yes; the purpose of the hash being to detect any change of state?
possibly