for me, it yes (security)
sys-gui solve the gui (is sys-audio possible)
@Quser59 you misunderstood the conversation. It was about some people advocating the project to switch to a different distribution for dom0.
I do not think there is any way for you to have any other distribution in dom0 than Fedora at this time, short of you single-handedly doing all the porting and development work needed to get there.
Also there is little value in doing this beyond " I don’t like fedra" … which is not a reason at all.
You are free to run all your qubes on Debian, Ubuntu, Arch … whatever you’d like and is supported. I use all debian-minimal and love it. Don’t like Fedora either, but it’s in dom0 and the reasons I don’t like it don’t apply there. Also I have basically no interaction with it … so what’s the problem?
2 Likes
Sorry if I was unclear, I just think (as I belive @ppc does, (correct me if I’m wrong there)), that fedora in dom0 is clunky: IF:(it is little work to port to alpine).
Hence my earlier question(s) about what is needed to be done. I know @adw referred me to some build-dependencies for the kernel, but I’m talking about comprehensively.
I’m guessing there has been some non-public conversation about this which I am not savvy to? What I’m asking is, if there’s anything I can do which is a good use of time to help migrate from fedora in dom0, please let me know.?
Perhaps I have misinterpreted this, but do you have a sys-gui enabled, or can you run dom0 headless(without gui)?
do you have a sys-gui enabled, or can you run dom0 headless(without gui)?
I am on R4.0.4 …
… so your beef is with XFCE? That’s an entirely different conversation and has only very little to do with the underlying distribution.
What are you trying to achieve? What is your motivation? I am pretty sure I don’t understand fully where you are coming from.
Replace fedora in dom0 without waiting for R4.1+. (ofc contributing work to the community, should such dev work be done).
Reduce vulns in dom0; (yes, I know what I am implying there).
No, but perhaps we should create a new thread?
is there any news i’m missed? i think qubes team don’t have any plan to use other distro for dom0 in default.
but if you want to play and do research, you can look at Qubes Admin API, How to create an AdminVM in R4.1
1 Like
Reduce vulns in dom0; (yes, I know what I am implying there).
I recommend you check your assumptions and make a clear case.
No, but perhaps we should create a new thread?
You are of course free to do so, but may I recommend reading all the discussion that already happened about this topic here in the forum and on github. Personally I have no appetite in going through all that once more.
A few hints:
- the choice of distribution in dom0 matters little today and will matter even less in the future
- dom0 is always offline / no remote attack surfaces
- as more and more hardware interfacing is moved into dedicated system qubes (sys-net, sys-usbm sys-audio, sys-gui etc.) the tasks for dom0 become less and less
- at some distant point in the future dom0 might be a Qubes OS specific minimal distribution
Short of real and major security benefits in moving dom0 to another distribution it is simply not important enough at the moment to distract from other more urgent development tasks.
Personal likes or dislikes for this or that packet manager / distribution are irrelevant.
2 Likes
Apologies, my wording was poor.
What I should have said, instead of ‘reduce vulns in dom0’, is this:
switching dom0 distro to lower TCB such as alpine has many advantages, (which I’m sure have already been discussed).
If something atop dom0 chains flaws to exploit the actual distro chosen, then it follows that a more secure distro reduces vulns - this is what I meant, (sorry I mis-spoke and wrote ‘in dom0’ - it was shorthand for what I meant).
Are you talking about a virtualization escape / Xen flaw?
cmiiw, I think you missunderstood, there’s nothing to do with fedora in dom0, what qubes provides is xen virtualization, in any case xen is more important than what any security that apply in dom0.
As example this attack Project Zero: Pandavirtualization: Exploiting the Xen hypervisor
1 Like
So my exact thinking was this:
qubes linux packages could have a vuln
that vuln could be really low priority/not necessarily a security concern
attacker exploits said vuln
they then chain this exploit with a fedora-specific exploit (granting access to dom0, as its fedora)
I think this is where @ppc may agree with me
But as you’ve said, this has probably been discussed already - however I felt emoldened by @ppc comment r/e alpine (i.e: they seem to agree alpine is better than fedora).
So I suppose it was more of a question than a statement - in reference to: how different are the libraries of fedora and alpine*?
*(because if they are radically different, then IMHO switching from fedora to alpine is a massive security increase - but of-course you will know far better than me the cost of the increase, and hence what the ROI/priority is).
I agree 100%, xen is more important than anything else - so if there’s more to do there I don’t mean to distract you - sorry if I have.
1 Like
No worries, currently fedora is somewhat better hardware support and only hosting graphical environment.
We can only wait until gui domain is implemented, then we can have much better play with dom0.
2 Likes
what about package installing @Sven
a lot because alpine is independent distro
if you what to use alpine then you should get started with APK 
1 Like
Is alpine bad or something, I’m not getting the joke?
android apk vs alpine apk
no
what about package installing
Let’s discuss that once we reach that point.
2 Likes
Which packages specifically does Fedora have that require it to be used as dom0?
Xen project undergoes a Synopsis Coverity scan which should also be the case for QubesOS. What types of attacks would Xen be subject to if it isn’t network facing?
Nevermind; It’s the guest VM which makes a hypercall; Xen doesn’t implement ASLR or PIE
If Debian/Devuan have such a large user base, wouldn’t it make sense to look at a Kicksecure hardened
Devuan as a dom0 alternative? Other options like HardenedBSD have a good reputation for security but the
user base is smaller.