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.
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:
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:
Build Xen with XSM enabled
Build the example policy
Add the appropriate “labels” to the VM config files, using seclabel=[$foo], based on their role.
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.
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.
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?