Does installing KDE have any tactical disadvantage to security?
We speak of stability. Stability and vulnerability go hand in hand, dont they?
I love the kde plasma desktop and I would like to have it. But it looks like a complicated GUI that probably is not as secure as something more simple. But again, the non-root GUI is not going to connect to the internet.
My previous feelings were to use one template for internet access and one for background/desktop/personal use. But that may not be needed since applications available in a template are not necessarily used in the appVM. Is that correct or would there be some data leak?
XFCE is something I havent used in a long time, but I will surely look into my customization techniques before I make a big move.
I recommend you listen to Chris here though. As mentioned some people are much more knowledgeable than I about security while I'm still only an early learner (and he's one of those who are much more knowledgeable). I also learned from reading his post as well. You can use my post to put forward new questions though (keep learning and dig deeper over time), but use Chris post for actual answers here regarding the security, he's way more credible. Notice too how he legit dismantles my argument "that Fedora is the slightly more secure one", when it turns out Debian appears ahead of Fedora in terms of security, and it seems like it might not be by just a little either. I stand corrected, I need to read more on this topic.
Keep learning though, it's awesome you ask and try find answers to questions like these.
About the stability going hand in hand with vulnerability, I view it the same way too, though it's not always the case if it isn't possible to exploit it, which also isn't always possible too.
Qubes once used KDE btw, you can find the discussion that made the change from KDE to XFCE5 here https://github.com/QubesOS/qubes-issues/issues/2119
Some of these issues I believe have changed though, what is perceived as "ugly" was back then a bit of an unlucky controversial statement due to different subjective opinions and it caused a bit of a stir in the KDE community. But I believe KDE also corrected some of those issues since then?
It's a good idea to keep your critical offline app's and data in an offline VM btw, keep doing that. You can also find multiple of official Qubes recommendations suggesting this offline AppVM move. For example the Split GPG guide in the Qubes doc's recommend this approach in order to keep your GPG keys more secure from being hacked. For example if only one application makes an outgoing opening in the firewall in the AppVM, then data in that AppVM might be opened to risk through exploits and attacks to that established connection. I have about 15-17 AppVM's which I use, not including the ones I don't use or templates, and I'm probably a light AppVM user compared to the more extreme ones. If it seems overwhelming though, try start with a set smaller number of VM's, then as you get used to it, try expand with a couple of VM's at a time. Think about what it adds to security or practical use-cases, and keep reviewing your VM layout :)
I believe there should be no issue switching between XFCE4 and KDE though, since the guide to KDE doesn't mention deleting XFCE4, just disabling it (at least it didn't at the time I read it). So presumably you should be able to switch between them with 2-3 commands in the tty terminal. You mihgt want to double-check that though, for example can you keep switching between them multiple of times without causing any harm to the system?
Correct. I have had both on and functioned fine.
For secuirty I see little difference other than maybe the amount of code. The more code ,all things being equal, the more possible holes errors surface area to attack.
The big issue with Fedora that Chris pointed out worries me though, with man in the middle attacks on the updating/install processes. Potentially anyone could then be targeted very easily, or are such attacks more exotic and tricky to perform in a real life setting? I don't suspect they are as easy as to allow script kiddies to do it, but it might not take the most skilled hackers around either? We're not even talking about infecting packages here, but just preventing critical updates from reaching the targeted update system. This seems like a very big deal, and appears to hurt fedora's reliability, trust and security. Maybe I'm blowing this out of proportion from reading this, but it just seems "Bad!" with a big fat capital letter B!.
If I was an attacker, this is certianly a method I would find feasible by the sound of it and try look into. Seen from an attackers PoV, why wouldn't an attacker use this method? It seems ideal and effective, which is what scares me about it.
If there is a way/method to circumvent and avoid this issue, then it needs to be made an issue that more people are aware about?
The strength of Qubes is that it takes resourceful and skilled attackers to get through, and maybe some social engineering to boot. It's not as straight forward as exploiting fedora seems to be. If something like this is "this easy", then it's very off-putting and worrisome, because then "anyone" could do it, and that to me seems to just undermine "everything". It probably matters less for dom0 though, but I'm certainly considering replacing fedora for debian on my sys-net, sys-firewall, and other online VM's with critical infrastructure, though not jumping to conclusions "just yet" either.
>In particular, Fedora's downfall is that its one of the very few distros
>that don't sign/secure their overall software manifest; a MITM attacker
>can prevent you from receiving specific bug fixes without you realizing
The above statement reminded me that it says that in the docs. And that does seem like a make or break statement for template choices. Key signing is a fine implementation on qubes.
ha, I did read that one too about the ugly kde.
@Yuraeitha
I havent quite tackled the security through compartmentalization part yet. I have put some thought into it though, and after dividing my attack surface between functions (keyring, passwords, misc files, etc) I realized that each function has only one app to go with it. So I may as well just have one app running in each VM. Or in the case of splitVMs, multiple apps for each program!
I would love to hear how you divide your VMs up. I was looking for examples online, but I couldnt find any; aside from an (ITL?) essay I read last year. But starting easy and growing is good advice.
>In particular, Fedora's downfall is that its one of the very few distros
>that don't sign/secure their overall software manifest; a MITM attacker
>can prevent you from receiving specific bug fixes without you realizing
The above statement reminded me that it says that in the docs. And that does seem like a make or break statement for template choices. Key signing is a fine implementation on qubes.
@Tim W
>Correct. I have had both on and functioned fine.
Thats good to know. I know I read somewhere that it was buggy with 3.2, I think?
As far a attack surface goes, I like using konsole better than xterm or uxterm and when installing that on debian or fedora, it required many dependencies. I removed it, but Im going to take a second look.
So, another infosec question Im trying to figure out...
Templates Vs AppVMs.
I find myself with, currently, 8 templates and growing.
This is because I am installing different programs in different VMs
and Im not wanting to install all my programs into a single VM.
Of course, one solution is to install all my programs into a single
templateVM and only enable the programs I need in the AppVM.
But it seems more secure to me if I keep different templates for
different needs and then create a AppVM to run them in. Is this
good or am I wasting my time and hard drive space?
For instance I have a template specifically for one set of
sys-net/sys-firewall and another template for sys-net2/sys-firewall2.
And another the vault and more to come.
I also made a launcher for all my Qubes scripts that I didn't keybind. They are definitely valuable for purposes like that as well :) You can also make scripts that sends commands into an AppVM from dom0, so essentially, you can securely control it from a secure domain, but also at the same time link keybinds in AppVM's to your keyboard or XFCE4 shortcuts. Scripting in Qubes is awesome. But be mindful of running dangerous or unknown scripts, they can do a lot of harm, in particular in dom0.
I suspect at some point we might be able to move scripts out of dom0 though, actually, it might even be possible now with USB keyboards? I'm not sure, I have to check that one day, it would definitely make scripts that control AppVM's more secure. But the issue here is probably the few scripts that control actions within dom0 though. For example changing screen resolution and move the screen to left or right, i.e. when plugging in an extra HDMI TV monitor or projector. This too might change in Qubes 4.1. as well when how graphics works in Qubes is changed. Well, there is definitely a lot of things to think about and reflect on, but that too in and on itself can be fun if you enjoy solving small puzzles like these.
heck even dating is becoming a new huge business these days, especially with all these new tools and algorithms to pair people. It makes sense to make an AppVM for stuff like that too, don't use your phone for it, and stay clear of the advanced dating sites.
This is a good example of data mining, where people might forget their privacy. It's essentially a gold mine for data mining, and we're probably gonna see huge industries in the coming years, privacy traded for love. It's a sad development. Nevertheless, AppVM's serves as a good use here too to minimize the profiling companies whom seek to profile everyone and know everything about you, so that they can sell your profile for profit to anyone who wants to buy.
There is some stellar advice in here! Im going to have to go back later and read this whole thread and write down bullet points...
Heres what I have so far.
Templates 3 catagories.
1) original (stripped of programs I dont want)
2) default (default template with minimal added functionality apps added)
3) network enabled
#2 is divided into
a. default (default template with minimal added functionality apps added)
b. EVERYTHING (everything that doesnt need internet access)
#3 is divided by program.
One for GPG keyring,
one for browsing,
one for banking,
one for keepassx...
and sys-net/firewall in one (which Im going to split now, Thanks Steve!)...
although keypass is not networked.
But thats all templates.