I know there are many old threads in which this has been discussed. I have spent quite a few hours trying to find the answers to my own questions in them, but it seems I can’t. So, I hope it is OK to ask what interests me in particular.
Please note, I am not questioning the authority or the expertise of the author. Not at all. I am willing to understand the logic of all that, as I am not an expert.
Please also note that I have already read multiple times the well-known answers “you can disable it if you will” and that “if something reaches dom0 it is game over”, and they are not the actual depth I am looking for.
The background explains:
# In Qubes VMs there is no point in isolating the root account from
# the user account. This is because all the user data is already
# accessible from the user account, so there is no direct benefit for
# the attacker if she could escalate to root (there is even no benefit
# in trying to install some persistent rootkits, as the VM's root
# filesystem modifications are lost upon each start of a VM).
The way I read this is: The user has full access to user data, so there is no point in not allowing full access to every other data as well, because that cannot damage the OS persistently. Sounds reasonable at first sight.
However, this also implies that, if a user process can damage user data, it is OK to let it damage the whole qube (
/rw included, resulting in persistence as well). It is also OK to allow malware which can damage some (or all) user data, to also read root-only-readable secrets from
/etc and potentially transmit them to an attacker (in case of an Internet connected qube), thus letting it reveal its full potential, rather than restricting damage as much as possible (which a restricted sudo would give).
I am also trying to relate that to each component of the InfoSec “CIA” triad, e.g:
In information security, confidentiality “is the property, that information is not made available or disclosed to unauthorized individuals, entities, or processes.”
Unless I am misunderstanding this, it also means that information which is only available to privileged (root) users and processes must not be disclosed to unauthorized ones.
My essential confusion comes from the fact that the “WTF document” seems focused on the security of the OS itself, not of data, and at the same time even that is contradictory - it explains how impossible persistence is, yet facilitates it.
It is somehow assumed that a small damage should not be a reason not to have a complete in-qube disaster. IOW, security becomes all or nothing - we can’t have the perfect security inside the qube, so let’s not have any in-qube security at all, let’s make it easy to break everything, reveal everything, make it convenient to the user to break things oneself, etc.
Naturally, the questions which arise are:
1. What is the logic of that? (especially in a security focused OS)
2. How does that fit the principle of least privilege?
3. Why use GNU/Linux at all? In Windows the user is always admin anyway.
Obviously, one can easily be tricked to reveal one’s root password to a malicious party. Yet, the very prompt itself is a raised flag saying “Hey, something wants escalated privilege, so be careful”, as confirmed by one of sudo’s authors himself. Is that not a good warning? How would removing it benefit security? Or why easiness comes first?
Recently, it SELinux support in Fedora templates has been anounced. On a Fedora’s forum thread I read this question and answer:
Is there any point in SELinux on the desktop if you enable passwordless sudo?
In the default configurations not really.
So, the logical question is:
4. What configuration does the new Fedora template use? Does SELinux in it actually protect from anything (and how), considering the default passwordless sudo? What good is it at all? What about Debian (is it less secure without SELinux)?
I hope someone can shed some bright light on all these matters.