This is not true. USB qube is created by default, unless you have a USB keyboard. In the latter case, it’s not created in order to not block the system from the user.
The inconvenient and somehow embarrassing truth for us – the malware experts – is that there does not exist any reliable method to determine if a given system is not compromised. True, there is a number of conditions that can warn us that the system is compromised, but there is no limit on the number of checks that a system must pass in order to be deemed “clean”.
I am glad that it’s the default, because it greatly simplifies the usage of Qubes. Otherwise I would have to remember tens of (different?) root passwords (or click “OK” tens of times per day). Qubes OS is already hard enough to use without that. I’m also glad that anyone can choose to switch the root password on if they like. Otherwise you are probably right and the attack surface (slightly) increases. Not too much for most people I would say.
“unless you have USB keyboard” means any non-laptop configuration. Also, I feel we all got misdirected in this thread. “Default hardening” is important, but it does not make qualitative difference – detection capabilities do. I will look deeper into the paranoid recovery mode, but it is not the only detection workflow worth following.
This is true. Note that Qubes OS is a reasonably secure OS, not maximally secure OS. New users without much experience will not be able to enjoy and stick with Qubes OS if they are constantly blocked from using the system due to the USB keyboard. (Same with the root password IMHO.)
Do you have a better suggestion how it should be done? By the way, this is the reason why it’s recommended to run Qubes on devices without a USB keyboard.
Anyway, we are back to hardening and I was trying to shift the focus to detection! People here are extremely concerned about ME/PSP as attack vectors, however, I think a scenario when an adversary would be willing to burn a precious ME exploit against Qubes user is even less likely… And you would not notice anything if the detection capabilities are not going to be in place :)))
Or to reliably prevent anything. We are all doomed, let’s just give up and lay dead.
Well, if anyone is interested, I would try to sketch what a good “Qubes-internal” IDS should look like.
Ok - my guess is that almost every one who contributes to Qubes has a
“day job”. Very few people are paid to work on Qubes: the rest of us do
it anyway.
If you have time to spend on the forum you have time to contribute imo.
User scenarios is something that has been discussed a number of times,
and there are some moves in this direction.
As to whether these things impact the user experience, imo the dom0
prompt becomes trivial click through like the Vista experience.
AppArmor is enabled by default in 4.1 - I suspect this will impact
user experience, particularly new and naive users, but we’ll have to
see.
This just isn’t so. People have been saying this for years, and there
are always people who take the opposite view.
In my experience, “normal” users can use Qubes perfectly well - they
don’t need expert understanding.
Sometimes they need support, but I don’t find this much different from
normal support requirements.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Strongly disagree here (as a guy who, in the 90’s and more recently, tried to have normal people use Linux desktops – though not in a professional setting). Normal people there are scared of what they don’t know, most of them do not even care to understand how the bloody thing works, they just want it to work without getting in the way.
Paradoxically the fact that Windows gets in the way of getting things done does not bother them as much, and I guess that’s just because “if MS does it that way they probably know better because you know, they’re everywhere, they must know what they’re doing”.
So maybe you rather meant “normal people in a professional setting”, where the tasks to be done are more well-defined, and support is readily available when needed ? That target would be easier to reach, and definitely the right direction IMHO.
Not in RC, probably – at least I had to turn it on manually in my Whonix templates. Did not notice any visible difference (which means it works as it should!)
Ok let’s start! (others are more interested in participating in endless rant about hardening)
Basically we need to
collect information
process it.
Both parts require a lot of thinking.
Collection: Can we make Windows VMs part of the process? (it is important, many people run Windows and they will continue to). Even if we stick to Linux, what exactly do we audit? Probably it is auditd and some integrity checks – how do we implement integrity checks? What is our baseline? What are things to watch on the private volume in general? What is the difference in approach to system VMs, templates and regular VMs? Do we need to check template integrity via digital signatures or is it out of the scope?
Processing: where do we store the collected information? How do we run analysis? What would be useful log retention? Most important, WHAT TYPE OF EVENTS are clear indicators of an attack, how do we keep SNR ration high enough? How we monitor changes (what type of changes) and how do we approve that the change was “normal” without creating huge management overhead?
Those questions may constitute WAY more complex challenges to manage one-user-environment than managing all this stuff in a corporate network with a dedicated security team.
And I am just barely scratching the surface. Should we do anything or everyone is busy discussing the hypothetical ME backdoor for last 10 years?
Where we could leverage the Qubes infrastructure, would be to setup a host IDS from outside of the VM to be audited. That is, audited VM offline, mount its volumes in IDS VM – at least for a first step, running an IDS test targeting a running VM would be cool but more complicated.
No, I meant what I said - normal users.
Yes, it helps if support is available when needed - I have said before
that giving someone Qubes without preparation, and without providing
support, does no favors, to them or to Qubes.
I’ve also said before that I don’t find the users on the forum a representative
sample.
I absolutely agree that it’s important to be able to use Qubes without
it getting in the way.
I’m not sure what you are “strongly disagreeing” with? My experience
against your experience? With my view (based on experience) that users
can use Qubes without expert understanding?
In any case we have wandered far from the subject in this thread, and
if we are simply going to trade opinions and experience, it doesn’t seem
fruitful.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
)