Passwordless sudo, SELinux - understanding security logic

User Support General
51

This is true. In other words, as I said above, removing the passwordless root would be a reasonable defense in depth. However, its existence by default indicates to new users that its security is much, much lower than the hardware virtualization, which is the distinctive feature of Qubes. Whenever possible, do not seriously and solely rely on root, if you have Qubes.

I don’t understand this discussion. To me, it seems we all agree that a root password would add a little bit more security. Joanna also agrees.

See also:

and

1 Like
52

@fsflover

That doesn’t conflict what I said.

1 Like
53

How so? Whonix already has no passwordless root. All other AppVMs do not protect your privacy by default, so your example is irrelevant in the context of this discussion.

54

However, its existence by default indicates to new users that its security is much, much lower than the hardware virtualization, which is the distinctive feature of Qubes. Whenever possible, do not seriously and solely rely on root, if you have Qubes.

Hardware isolation is surely much stronger than software one. Both are not necessarily self-exclusive though. One paradox here (as I shared in another thread) is that we do have the possibility for additional hardware isolation (4 protection rings on x86), yet in Linux we use only 2 (kernel and user) inside the qube. Xen adds one more but 1 unused still remains. I wonder if that has been proposed or discussed anywhere. But it’s off-topic.

I don’t understand this discussion. To me, it seems we all agree that a root password would add a little bit more security. Joanna also agrees.

She didn’t say anything about a little bit. What I read is that she obviously no longer maintains the firm position outlined in the “WTF” document (thus making it old and needing an update) but wants to have restricted root, just done properly, so that it is strong enough.

Personally, I neither agree or disagree. That is the whole point of the current thread - to clarify the logic because the reasoning in the “WTF” is somewhat unsound. It seems to me a good idea someone to update that page, so that it explains better. As it seems, currently it has created more of a religious belief (Joanna said so. Period. Don’t question it), rather than showing the whole picture (including that same Joanna saying something else later).

4 Likes
55

Anonymity != privacy != security
They are often related but not equivalent. There are cases in which they may be completely unrelated.

Whonix is focused on anonymity. My example is relevant because if system logs (and other system components) contain additional system-specific information (as they usually do) that may facilitate deanonymization. Having an additional border may make this more difficult.

1 Like
56

You should give a link to that if you want this discussion to be on point (I tried but couldn’t find anything by now).

Isn’t this Issue relevant here? I’m no expert but to me the answer looks the same: anonymity and privacy are only provided by Whonix.

Another relevant discussion:

57

Each time when I see something is lacking in the documentation and ask about it, someone repeats that it is a community effort (you did it twice in the current thread), suggesting that it is me who has the write the documentation. IOW, I am supposed to somehow already know what I am trying to learn. :slight_smile:

You should give a link to that if you want this discussion to be on point (I tried but couldn’t find anything by now).

You shared the link yourself. It was shared earlier in the current thread too and commented on.

Isn’t this Issue relevant here?

TLDR. From the title it seems a different issue (different deanonimization vector).

I’m no expert but to me the answer looks the same: anonymity and privacy are only provided by Whonix.

Run lscpu in a Whonix VM and you will see if Whonix knows what your CPU is.
As for the potential case I am talking about, again in a Whonix VM run:

journalctl -k

and compare it to:

sudo journalctl -k

1 Like
58

Hi qubist,

I might be misunderstanding you so feel free to correct me. But it sounds like what you’re trying to do is figure out what the “right answer” is in terms of choosing to enable passwordless root or not. The problem is that when it comes to security, there is no “right answer”. There are tradeoffs which increase security at some cost, usually availability or convenience. There are good reasons to disable passwordless root if you the possibility of someone obtaining a vm escape is part of your threat model. However, this comes with usability drawbacks and for many people the increase to security is not worth this drawback. For example, if someone has an exploit this valuable they are likely not going to use it in order to drain the bank account of a random person. Instead, they would use it to attack the infrastructure of a bank, or the developers who maintain the software that banks rely on. So for a lot of people passwordless root makes sense.

People who find their way to this forum are naturally going to be more concerned about a wider variety of threats than the average person, for whatever reason. So it makes sense that there would be a disproportionately large number of people on this forum who decide to disable passwordless root. There is nothing wrong with that. It also makes sense that the vast majority of people would want passwordless root. There is also nothing wrong with that.

From the contents of this thread, it seems like you understand the security benefits of disabling passwordless root. Whether or not these are with the usability costs is a judgement each person has to make for themself.

5 Likes
59

I still don’t understand what “usability drawback” a password-entry for sudo command brings.

60

@skyvine

I might be misunderstanding you so feel free to correct me. But it sounds like what you’re trying to do is figure out what the “right answer” is in terms of choosing to enable passwordless root or not.

Not really. As I said, I am neither against, nor for either of the two alternatives. What I am trying to figure is the actual reasoning behind the “WTF”, as the superficial text it provides is not it. I say superficial, because I have read a lot of amazingly deep stuff by Joanna, based on which I simply refuse to believe that this is the actual and complete reasoning. Her later comments on GitHub also confirm that there is more to it.

The simplification “VMs are perfectly isolated, so root needs no password” seems easily accepted by the majority as “the right answer”. Parallel to that, the same people repeat the other mantra - that there is no perfect security. So, they both assume that VMs are perfectly isolated and that there is no perfect security. I wonder how many have actually dug deeper into that, as DMA attacks are actually possible even with IOMMU (contains also links to Joanna’s papers on the subject, showing that those are possible). And that this is just one thing, found through quick search, not a complete study of the subject.

Another fact, worth considering IMO, is that nothing so far looks at the possibility of flaws in this whole “perfect isolation” which may be discovered in near or far future. Side-channel CPU attacks, for example, were not a thing just a few years ago. They changed quite a lot the security considerations after appearing though. That is a different discussion though.

So, I hope you understand the source of my confusion, as well as the effect of the “WTF” on the community (which we see even in the current thread). I was hoping that someone with deeper expertise and understanding of the whole matter would be able to provide a more meaningful clarification (ideally, even update that doc). Then, anyone reading it would have a better basis to decide for oneself how and why to act considering case specifics, not merely be given “freedom to do what you want” (including to fool oneself).

The problem is that when it comes to security, there is no “right answer”.

The even bigger problem is that there are so many wrong, yet easily accepted, answers.

1 Like
61

Using a script to enable sudo prompt for VMs

 

I’m not about to waddle into this conversation again–I just want to post a convenient way to enable sudo prompt.

For those who missed @anon22772651’s posts, what this does is it generates a dom0 prompt similar to what is presented when moving files between VMs. However, all the user needs to do is press ‘enter’, so the inconvenience is minimized.

Those who feel the need to should implement this, while those who don’t should just go on with their merry lives.

 

 

You don’t have to install vm-boot-protect to get sudo prompt–just run configure-sudo-prompt. The author, @Tasket is a recognized contributor (or on the Qubes Team) and his code is short and widely used, therefore scrutinized, and therefore trustworthy. His other scripts are well worth looking at too.

I’m not sure whether any of the above will work with 4.2. In fact, can anyone tell me whether vm-boot-protect and vm-boot-protect works with 4.2?

 

Merry Christmas and a (reasonably) secure new year to all.

7 Likes
62

For example, I have a few scripts that automatically install software and run it every time I run a qube. (Or every time I need it.) You can’t do that conveniently with a dom0 prompt. It saves me another template. And I frequently shutdown qubes from the command line without any prompts as well.

This is completely illogical, and I didn’t see anyone saying that except you.

VMs are isolated reasonably well. Root isolation doesn’t provide a reasonable security but adds friction. For most Qubes users, it’s expected that this additional friction is not worth it. I am one of such users. Using Qubes itself is already a huge jump in security. It’s sufficient as a first, big step. It’s already hard enough, so we have very few users.

63

As far as I understand, passwordless access in qubes now works only for convenience. You can use any option in your qubes:

  1. Don’t install the package that provides passwordless access, and use qvm-run -u root namevm namecommand from dom0
  2. Use dom0 hint
  3. The standard passwordless option

It’s up to each individual to decide which option to use.
And in general, using sudo password or dom0 hint is not a panacea. Personally, I only use the dom0 hint for personal control and I am aware of the fact that if someone attacks me, the sudo password and dom0 hint will not save me (lucky if xen survives the attack, otherwise it’s game over). I think people should care more about organizing their qubes and separating important information. You probably wouldn’t run untested scripts in appvm where bank data is stored, etc.

I’d like to summarize by saying that qubes developers are aware of many security issues and are working on them, but they don’t have infinite resources to meet all the requests for system enhancements. It all takes their own time.

1 Like
64

For example, I have a few scripts that automatically install software and run it every time I run a qube.

If something is automatic, you should not need to do anything additional (neither with sudo, nor without). That is zero burden to usability.

And I frequently shutdown qubes from the command line without any prompts as well.

Even if we assume that typing commands is a usability feature at all, qvm-shutdown from dom0 is just the same and requires zero passwords.

This is completely illogical, and I didn’t see anyone saying that except you.

Post 21 (+ various additional implications I am not going to analyze):

an isolated system that can’t harm anything else around it

VMs are isolated reasonably well. Root isolation doesn’t provide a reasonable security but adds friction.

Argue with Joanna on GitHub, not with me. She wants to re-enable restricted root. I am just looking for clarity.

For most Qubes users, it’s expected that this additional friction is not worth it.

It is not expected. Nobody expects passwordless root by default on a *nix system, otherwise there would be no “WTF… are you crazy”. It is made expected through and because of the “WTF”. So, only established and educated users expect it. That’s why all the arguments about “usability”, and “for beginners” make no sense.

2 Likes
65

@Asterium

It’s up to each individual to decide which option to use.

The community effort (aka documentation) does not explain in which cases one should use one or the other and why. It just says “WTF” and (almost) everyone repeats “WTF”, attacking those who dare to ask about it. It’s like an indirect veto on the topic served with a libertarian “but you are free to do what you want” (without necessarily knowing why and without talking about it who are simply comfortable with the default).

1 Like
66

I am guessing adding those package installation commands to /rw/config/rc.local doesn’t satisfy you?

I don’t think @qubist disputes this, neither do I. The problem is trying to understand the logical reasoning behind having passwordless-root as the default mode of operation inside individual qubes.

I agree with the line of reasoning here. EDIT: I only agree up to the last sentence. I think the last sentence makes the error in assuming that only beginners are linux user beginners. Many Windows users who come into QubesOS wouldn’t expect a password entry for doing admin actions.

2 Likes
67

After this many posts, and from previous discussions, I am inclined towards accepting the passwordless-root decision as an anachronistic element of QubesOS. It’s always been like this, so no point in asking why it is like this. If you don’t like it, you can of course change it. But I am at the point that I believe nobody is able to propose a logical, coherent explanation that went into saying “let’s have passwordless root anyways” back in the old days of QubesOS. Probably it made the early developers’ and maintainers’ work easier, and it stuck with the users, as well.

2 Likes
68

If you have malware on your computer that can read/write your home directory, I think sudo without password is the least of your problems. You can go deeper into this topic, talk about X isolation, etc. There are many options to get around the sudo password to whoever is performing the attack. Focus more on splitting work into different qube, run dangerous and unverified documents in disposableVM, everyone will benefit.

As for the documentation, it is outdated in some places, not clear (illogical) in some places. Most of the documentation is the work of the community, if you are an expert in some area that will help those who use qubes, you can make a request to add or update the documentation.

1 Like
69

@tanky0u

I think the last sentence makes the error in assuming that only beginners are linux user beginners.

To me a beginner is one who begins using computers. Otherwise one is already experienced (more or less).

However, since neither beginner or advanced user (used also in docs) have clear definitions, they are pretty much abstractions and subject to misunderstanding. In the context of the current thread: WTF is an advanced user? How does one become that? Is a beginner supposed to edit the “community effort” in order to find out? Vague stuff.

1 Like
70

@Asterium

There are no flashing red lights and big signs saying “You have malware in this qube”. Proceed from there.

I don’t see why the right way to work securely should be to deliberately disable all in-qube restrictions and trash qubes all the time. We distrust the infrastructure, the hardware, even the distro packages (which touch even offline qubes and even super-mini-micro-nano-templates) and don’t want to fool ourselves that anything is secure. This is a vicious circle. If we follow that line - let’s trash computers too.

1 Like