I found it interesting reading that it was mentioned about the Surface Attack on some things related to QubeOS because it was small in size, like the code, not containing much, therefore limiting the Surface Attack.
Ok, GREAT point, but what about the IDEA that if you use a BIG DISTRO like Fedora and the MASSIVE SIZE of the repos and the software contained in it, this sounds like a BIG SURFACE ATTACK area, instead of going with a smaller distro with a smaller surface attack area, considering it on the level of the package/repo size and the smaller amount of people involved, I personally think this is a smarter choice to go with.
Look at Slackware as an example, I believe on the level of package security it has a smaller surface attack area when compare to Fedora by the limited amount it contains in it's repo and the smaller amount of people involved with the code.
I believe you limit the amount of hands dealing with code you also limit the amount of bugs being introduced by all the mistakes all these hands can make and introduce, of course a lot more hands sometimes is good to fix things, but I hope you can see the point here.
Like I heard it mentioned before; 'Less hands in the cookie mix makes for less of a cooking mess' and I think this can also apply to code.
I personally think that if QubeOS needs to be based off of another distro because of the limited skills needed to make it from scratch, or limited resources, I think there are much better choices to go with from a security stand point instead of Fedora.
What do others here think?
It's also my understanding that Slackware is a more secure system compared to Fedora, Fedora just offers more goodies to the end-user that want a more complete out the box experience.
If you can get a Slackware version working, for Dom0 as well as Guests, I know many people that would switch over to Qubes.
There are many people that hate SystemD.
Also, having a stable platform, one that isn't releasing a new version every 10 seconds like Fedora, and only just updates to the system to ensure security would be of great advantage.
If you can get it done with Qubes 3.2, that would be perfect, since Qubes 4.0 will not work on much hardware that people use these days (according to the requirements).
There are a lot of packages creating a bigger attack surface. but, bigger distros like fedora have companies behind them like red hat. red hat has been pretty good about actively looking for vulnerabilities in those packages. distros that automatically upgrade to the latest version (gentoo etc) can also burn you. they would make better template vms where your more likely to want newer software and new issues can be better contained.
for dom0, newer distros are better at hardware compatibility with those fancy new processors, graphics cards and storage controllers in laptops.
just personal opinion, but wayland is a better fit than x11 for qubes in the long run. fedora is the only distro with a dedicated security staff actively supporting it.
anytime you abstract a layer, your diluting your resources. maintaining a dom0 isnt much more work than a domu template, but if you want to add slackware, arch, and gentoo, youve now more than doubled the developers distro maintanance work when they could be working on stability and features.
Qubes is aimed at home desktop users I believe, so they want something easy to manage, and they also want broad hardware support.
That being said there are things like the latest drive by downloads affecting fedora and google chrome, but that would affect appvms not dom0.
But should be noted, fedora and ubuntu were affected with the latest encryption bypass. (holding enter key down) debian was not. So if not fedora my vote is for debian. But those are the only two i would nominate.
I had a quick look at
https://www.qubes-os.org/doc/templates/
And along with Debian which is installed by default both
Arch and
Ubuntu
Are available...
My personal preference in Ubuntu because it generally just works, and Arch because it has the latest version of everything when every you have the problem that xyz does not work because it needs the latest version. That the distribution maintainer has not yet made available in your favourite distro. I have not yet tried these templates.
Since I am a xfce fan I love qubes UI along with all the other parts.
Only gripe is no Win10 template ( and the various issues getting Windows to work - no password ).
Regards
Ronald
> My personal preference in Ubuntu because it generally just works, and Arch because it has the latest version of everything when every you have the problem that xyz does not work because it needs the latest version. That the distribution maintainer has not yet made available in your favourite distro. I have not yet tried these templates.
>
> Since I am a xfce fan I love qubes UI along with all the other parts.
I am an xFCE fan as well. It's a simple interface and just works smoothly, unlike KDE and Gnome which are so bloated.
> Only gripe is no Win10 template ( and the various issues getting Windows to work - no password ).
I have found no issues getting windows to work with no password. I just set the auto Login, and done.
There are no tools for Win10, so until then, all good. But if you want to use the tools, stick to version 3.2.1.3 until they fix them, because the tools got broken in version 3.2.2.3, and I have not seen a version that is fixed yet.
I disagree with Snowden on this, if it aint broke don't fix it. What usually happens in reality is the newer software introduces even more bugs then were originally there imo for the sake of new shiny things. Many experts say we are actually less safe nowadays cause systems are already too complex. And if new exploits found in old software are patched with security updates then I think the freesoftware communities have it right when it comes to security.
If he means old software thats no longer maintained and abandoned then he has a good point. There is plenty of that in every linux distro, some more then others.
But saying attackers adapt quick, means to me adapting to something new, adapting to a new exploit, not a secret one they've already known about.
I use to believe that always updating software would remove exploits currently in them. But usually in reality if not specifically addressed, since new software is still built upon the same old software, the old bugs still exist while new ones are now introduced as well.
If you have a secure system in the first place, the exploits can't get a grip easily.
If you manage your system you won't get hit easily.
If you lock the machine down, you won't get hit easily.
I limit SUDO activity to what I want to let things use.
I don't let sudo change passwords..
I don't let sudo do anything of impact for the system.
I have firewall set up so that I have to permit what I want, and I monitor all traffic.
So updating the system to the latest, will often break things, along with security. So I don't update until I know that the update will actually fix it and not break the security I have in place that fix's what's actually wrong, if that makes sense?
Moving to Slackware, AWAY from SystemD removes one HUGE security flaw that will never be fixed.
it MAY get a few tiny holes/vulnerabilities, but they are easy to protect against, where as SystemD, you can't protect against SystemD.
I've asked this before, and none answers the question.
Can you, from that, tell me what are REQUIRED for Qubes-OS to be fully functional?
If you can, then you must be able to see something that I am not able to.
While that may have a list of a lot of packages, it doesn't say what versions are required.
Group: Qubes
Vendor: Invisible Things Lab
License: GPL
URL: http://www.qubes-os.org
BuildRequires: ImageMagick
BuildRequires: systemd-units
# FIXME: Enable this and disable debug_package
#BuildArch: noarch
Requires(post): systemd-units
Requires(preun): systemd-units
Requires(postun): systemd-units
Requires: python, pciutils, python-inotify, python-daemon
Requires: qubes-core-dom0-linux >= 3.1.8
Requires: qubes-core-dom0-doc
Requires: qubes-db-dom0
Requires: python-lxml
Requires: python-psutil
# TODO: R: qubes-gui-dom0 >= 2.1.11
Conflicts: qubes-gui-dom0 < 1.1.13
Requires: libvirt-python
%if x%{?backend_vmm} == xxen
Requires: xen-runtime
Requires: xen-hvm
Requires: libvirt-daemon-xen >= 1.2.20-6
%endif
Requires: createrepo
Requires: gnome-packagekit
Requires: cronie
Requires: bsdtar
# for qubes-hcl-report
Requires: dmidecode
Requires: PyQt4
Dom0 is created by installing qubes tools that pull in their dependencies and so on. Yum Extender in dom0 can give you all the prerequisites. Of course here we rely on developers being precise when defining them.
I'm sorry that I was not more specific when I said "needs". It can be taken multiple ways, I should have been more precise.
>Every Qubes specific package provides a list of prerequisites and version conflicts.
That is true, but that's why I'm curious about it to know.
That is true.
Thing is, I'd be building it from code, which is why I need to know. Because not everything is as simple as using an RPM or other package like that. And there are no SRPMs so that's another thing that makes it not work well for what I need to do to get the packages installed to create a new Dom0.
But that's just the way things go unfortunately.
I can but try.