To SUDO or not to SUDO?

General Discussion
21

Joanna was extremely adamant about that from the very beginning, but I reserve my right to simply disagree. Whatever helps, helps. If it costs next to nothing, why not. No one proposes weakening existing security mechanisms in favor of less reliable ones, stacking them up is another matter.

2 Likes
22

thanks, sorry but I don’t understand what you mean by this:

Holding the Shift key in qui-domains is even easier.

1 Like
23

This seems to me to be typo from Joanna?

Indeed, one can use qvm-run -e root -p to get “raw”, shellcode-like access to the VM

I never heard of -e ? -u ?

1 Like
24

It is interesting that almost everyone seems to agree that:

Preventing malware from gaining root is vital to prevent malware from breaking out of a VM, spreading to dom0 or other VMs. Many attacks aren’t possible with root and/or kernel level compromise.

and yet passwordless-root remains default.

Also in regards to the qvm-run -u root alternative, I found this interesting:

Regarding point 5, another concern is that a typical user would run the qvm-run command from a terminal that supports escape sequences (even if their intended use without a PTY inside the VM makes little sense) - and this opens up significant attack surface on Dom0 for attacks from the VM.

So… :rofl: I find myself again, an Idiot Qubed with this question..

1 Like
25

What do you want, security or usability?

26

Security (by as much as possible minimalism.) I need to understand the parts. Remove the unnecessary, I try to keep it lean and simple.

Security within the VMs is also important for my T.M. Which is why I keep coming back to this passwordless-root / qvm-run -u root question.

edit: Although, I should add that I use terminals and sudo quite a bit within VM’s so passwordless-root does come in handy compared to qvm-run -u root

1 Like
27

Then you will at least need to create your own custom templates, the minimal ones you are using are not actually minimal as referenced by various previous topics due to meta-package dependencies.

28

That is a continuous process yes. I learn and try to adapt.

1 Like
29

Bold statement, and pretty much meaningless.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

1 Like
30

Not for the first time, not what I wrote:

That’s a bold statement, and meaningless.

As I’ve said before, use of passwordless root in Cloudland is not
unusual, but we dont see hordes of malevolent agents there.

Is there any evidence that in Qubes passwordless root has resulted
in malware breaking out to dom0?

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

1 Like
31

Thanks for chiming in @unman

Actually my primary concern is not so much passwordless-root resulting in malware breaking out to dom0 but malware / security within the qube itself.

see my post above To SUDO or not to SUDO? - #7 by James369

1 Like
32

I still agree with Joanna’s argument. The most important thing is to keep the TCB small.

Don’t rely on anything based on traditional operating systems with uni monolithic kernels. If there is a way to escape the VM, this must be fixed on the XEN side.

If I needed more boundaries, I’d compartmentalise more finely.

1 Like
33

Well, for me dialog-driven sudo is not a usability nuisance. Especially if I run third-party install scripts or agentic stuff in qube: visible signal helps me to pause and think. It is even more an attention barrier rather than security barrier. For some qubes I even keep qvm-run from dom0 an only sanctioned root path.

2 Likes
34

As you referred to my post, I’d like to clarify my point.

I consider sudo ineffective at protecting users from malware running outside a sandbox. Requiring a password provides very little additional protection compared with passwordless sudo, because malware running with the user’s privileges can often manipulate the user’s environment—for example, by modifying shell startup files such as .bashrc—and influence commands the user later executes with elevated privileges.

In conclusion, relying solely on commands executed through SUID binaries is insufficient. For meaningful protection, we should use sandboxing technologies such as Firejail or Flatpak to isolate less-trusted programs. Another possible approach is the proposed Multi-Kernel Architecture, although it remains only a proposal at this stage.

My current approach is to keep passwordless sudo and use Flatpak or Firejail for less-trusted programs. sudo itself is not particularly important to me. I hope this helps clarify my position.

2 Likes
35
  1. Click the cubic icon on panel
  2. See your running qubes list unfold
  3. Hover on some qube name
  4. See the unfolding menu - one of the commands is “Run Terminal”
  5. Press the Shift key and it changes to “Run Root Terminal”
5 Likes
36
  1. Click the cubic icon on panel
  2. See your running qubes list unfold
  3. Hover on some qube name
  4. See the unfolding menu - one of the commands is “Run Terminal”
  5. Press the Shift key and it changes to “Run Root Terminal”

Wasn’t aware of this. That’s great.

2 Likes
37

Traditional operating systems do not use unikernels. After MirageOS, the next partial unikernel implementation in the Xen ecosystem is Liteqube with Mirage Firewall.

1 Like
38

Sorry. It was too early in the morning. I meant “monolithic” (vs. “micro”), not unikernel. Statically linked software got that speeeeeed :wink:

1 Like
39

In qubes that don’t have qubes-core-agent-passwordless-root (what the OP asks about) there is no password one can type to gain root privilege. One needs dom0 access to do that, i.e. it is not some password that provides protection. How can malware run as root in such environment?

1 Like
40

Not sure I follow.

Flatpak provides no meaningful isolation on Qubes OS. It just needs to misuse X11 to break out of the sandbox. Firejail must be run with xpra or xephyr, to provide some isolation on Qubes OS, but last time I tried, both crashed.

Probably not, since Qubes OS makes it easy to escalate privileges from unconfined user to root, no matter, if you use passwordless sudo or not. That it’s so easy is suboptimal, since escalating to in-VM root is often a prerequisite for VM escapes and it makes in-VM sandboxing much more difficult.

1 Like