Here is a list of things than could be done to harden QubesOS:
This isn’t appropriate for “User Support”.
All you have done is aggregate stuff from your other threads without
comment or commentary. It’s lazy, and just noise.
Why don’t you add notes on what is being done at present, and point to
other discussions, or Github issues? That would be more useful to other
users, but it would take some work from you.
I agree that it isn’t user support, it should be in ‘general discussion’. My apologies.
The main concern here, and you’ve been told multiple times, is that your content does not bring any contribution to the table, whatsoever.
Posting random links or making lists out of the blue, can hardly be helpful. Instead, you could focus on fewer topics and try to digest them and highlight the benefits, how they could be implemented, and any other additional useful information.
Perhaps update your existing threads before creating any new ones.
Otherwise your posts are just completely pointless.
Cheers
It isn’t helpful to provide resources on hardening and put them in an easily accessible place? I agree its
in the wrong section of the forum, but I don’t think it will hurt anybody.
Here are some links for any researchers looking to fuzz dom0 for VM breakout vulns:
https://intellabs.github.io/kAFL/tutorials/fuzzing_linux_kernel.html
oh and Nyx:
I dont see the point in these lists - if you have reviewed and tested
the contents, say so.
A few comments could really add substance.
Also, in what sense are these “User support”?
It’s general discussion surrounding hardening techniques.
Great choice of words. Then why do you keep posting all these random links in the User Support category? Every day I find myself moving your requests for security features out of the support category.
yeah it’s the second option in the dropdown; will adjust this…
Considering Xen uses Coverity scan for its own security scanning; are there any plans to scan QubesOS
using Coverity Scan?
Has the QubesOS community any interest in projects like Xoar (dom0 dissagregation)?
As described in the following links:
https://wiki.xenproject.org/wiki/Dom0_Disaggregation
http://www.jbcse.com/projectsFolder/CS643%20-%20Xoar%20Presentation%20(2).pdf
How can the attack surface of Xen, the bare metal hypervisor, be reduced?
https://trustworthy.systems/projects/TS/makatea
https://sel4.systems/
***replacement of xen with SeL4
Well done with the catchy title! Hope you don’t mind I made it slightly less flashy. And this isn’t a support request and isn’t QubesOS-specific. You should ask this in the Xen community perhaps.
Also, you just keep posting a bunch of links and documents without any meaningful contribution to the discussions you start. What’s the point? Why don’t you at least try to provide some context? Or maybe expand on your goal or possibly even propose a solution?
All these files and extremely interesting links you’re sharing, have already been posted multiple times in the forum, so perhaps a bit of “search-button-research” might prove beneficial to your endeavor.
Update:
the title changed, hence a different thread. Sorry for the noise, I should stop posting and go sleep.
Original:
@deeplow it’s happening again: @BEBF738VD’s answer is the first I saw of this thread.
My mail provider doesn’t show any outage in the timeframe of this thread.
It is a request to fork QubesOS to have a version which uses SeL4 as a hypervisor as opposed to Xen.
The Xen project is unlikely to replace its hypervisor with SeL4 as they are two different projects. But
QubesOS may be capable of using either Xen or SeL4 as a hypervisor. Its not really an “issue” per se but
a discussion on where Qubes might look to reduce its attack surface in a general sense.
Do you actually mean fork?
Who do you think will work on this new project?
In any case, as it currently stands, SeL4 isn’t yet verified for x86-64,
and the proofs exclude VT-X and VT-D. It isn’t verified in hypervisor
mode so there’s a long way to go. You’re talking as if SeL4 is a viable
alternative for Qubes: it isn’t.
Maybe a more realistic hardening project would be to implement the Nexen model of Xen as described in
the following paper:
As it mitigates a whole class of attacks against the hypervisor as described here:
https://ipads.se.sjtu.edu.cn/xsa/
It looks like specific functions performed within the hypervisor are split off and created as their
own VMs, and based on privilege level, these VMs are read-only, read-write or not accessible in
memory.