OpenQA test result for build 2025051404-4.3

[qubesos-bot]

OpenQA test summary

Complete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025051404-4.3&flavor=qubes-whonix

Installing updates failed, skipping the report!

[marmarek]

@adrelanos whonix-workstation-17 reliably fails to update. The only messages from qubes-vm-update I see are:

whonix-workstation-17:out: [INFO] You are using the sysmaint account. This account has sudoers capabilities. Proceed with caution. See also: https://www.kicksecure.com/wiki/Sysmaint
whonix-workstation-17:out: 
whonix-workstation-17:err: [INFO] You are using the sysmaint account. This account has sudoers capabilities. Proceed with caution. See also: https://www.kicksecure.com/wiki/Sysmaint
whonix-workstation-17:err: 

I'm not yet sure if they are related to the failure. Interestingly, no such problem on whonix-gateway-17.

It worked just fine 2 days ago, so it must be some very recent change. Also, I don't see this failure on R4.2

[marmarek]

Ok, this is weird:

user@dom0:~$ qvm-run -pu root whonix-workstation-17 apt-get update
Reading package lists...
E: List directory /var/lib/apt/lists/partial is missing. - Acquire (13: Permission denied)
user@dom0:~$ qvm-run -pu root whonix-workstation-17 id
uid=1001(sysmaint) gid=1001(sysmaint) groups=1001(sysmaint),27(sudo),100(users),111(console),113(ssh),997(qubes)

No wonder update fails...

[marmarek]

@ArrayBolt3

[marmarek]

We have qubes.VMShell and qubes.VMRootShell, but not qubes.VMRootExec... So, when qubes.VMExec is forced to sysmaint user, it affects also calls intended to be root.

[marmarek]

Based on news on the Whonix forum (for example https://forums.whonix.org/t/whonix-17-3-9-2-testers-wanted/21543) this change should be there in the last week tests too, yet that one succeeded. Maybe due to the template build issues (so the template was still the old one)? Besides fixing the actual issue, breaking updates is a serious problem, and we should ensure tests detect that early.

[marmarek]

What is the best place to track this (two?) issues? Here? Some other Whonix repo? Forum thread? Or maybe qubes-issues?

[adrelanos]

Thank you for reporting this!

whonix-workstation-17:out: [INFO] You are using the sysmaint account. This account has sudoers capabilities. Proceed with caution. See also: https://www.kicksecure.com/wiki/Sysmaint

Source file: /usr/share/user-sysmaint-split/conf/profile.d_20_sysmaint_warn.sh

Will be on the system in location: /etc/profile.d/20_sysmaint_warn.sh

Why would id -un be sysmaint for qubes-vm-update?

Seems like qubes-vm-update gets confused by the extraneous output? Should that be considered a Qubes bug?

/etc/profile.d/20_sysmaint_warn.sh is just an informational script supposed (primarily) for non-Qubes users logging into a virtual terminal. I think we must be more careful and only show output if running inside a real tty (maybe maybe some other conditions such as stdin connected, I need to think about).

Might be R4.3 only due to:

• Allow VMs to specify boot modes as being only intended for AppVMs or templates QubesOS/qubes-issues#9920

Maybe due to the template build issues (so the template was still the old one)?

Maybe but they both come with user-sysmaint-split already. Changes are only minor (systemcheck related and such). So that's also weird.

Interestingly, no such problem on whonix-gateway-17.

At the time of writing,

• we install user-sysmaint-split by default on Whonix-Workstation (new builds only);
• we don't install user-sysmaint-split on Whonix-Gateway.

(Details on installation status and rationale here: https://www.whonix.org/wiki/Sysmaint)

Ok, this is weird:

user@dom0:~$ qvm-run -pu root whonix-workstation-17 apt-get update
Reading package lists...
E: List directory /var/lib/apt/lists/partial is missing. - Acquire (13: Permission denied)

Ok, that is really weird indeed. Why would root have no permission... Works for me with Template from community testing.

(Probably unrelated to user-sysmaint-split: We're not restricting root in any way.)

Could you please check permissions:

sudo ls -la /var/lib/apt/lists/partial
sudo ls -la /var/lib/apt/lists/
sudo ls -la /var/lib/apt/
sudo ls -la /var/lib/
sudo ls -la /var/
sudo ls -la /

(As far as that makes sense, as long as it shows something unexpected.)

What is the best place to track this (two?) issues? Here? Some other Whonix repo? Forum thread? Or maybe qubes-issues?

Perhaps here: https://forums.whonix.org/t/qubes-sudo-su-root-hardening-development-discussion/8561/70

But 1 issue = 1 ticket (or 1 forum thread) would also be great.

[marmarek]

Seems like qubes-vm-update gets confused by the extraneous output? Should that be considered a Qubes bug?

I don't think it's the extraneous output issue.

Ok, that is really weird indeed. Why would root have no permission... Works for me with Template from community testing.

See the second part of that code segment:

user@dom0:~$ qvm-run -pu root whonix-workstation-17 id
uid=1001(sysmaint) gid=1001(sysmaint) groups=1001(sysmaint),27(sudo),100(users),111(console),113(ssh),997(qubes)

Looks like sysmaint overrides the user to be always sysmaint, even if it was requested to be root. I do see /run/qubes/rpc-config/qubes.VMExec with force-user='sysmaint'. That's most likely the cause. #240 (comment) is some idea what could be the solution (but not sure if the best).

[marmarek]

/etc/profile.d/20_sysmaint_warn.sh is just an informational script supposed (primarily) for non-Qubes users logging into a virtual terminal. I think we must be more careful and only show output if running inside a real tty (maybe maybe some other conditions such as stdin connected, I need to think about).

Yes, outputting such message in non-interactive session (especially to stdout) confuses several tools, including scp, but I think qvm-copy too.

[ArrayBolt3]

We have qubes.VMShell and qubes.VMRootShell, but not qubes.VMRootExec... So, when qubes.VMExec is forced to sysmaint user, it affects also calls intended to be root.

@marmarek To be clear, the suggested solution is for a non-overridden qubes.VMRootExec config file for qrexec to be made, so that the updater will call that and be able to bypass the sysmaint account when running an update? (Don't know if my terminology is right but I think you get what I mean.)

[marmarek]

To be clear, the suggested solution is for a non-overridden qubes.VMRootExec config file for qrexec to be made

Yes.

[marmarek]

Looking at the qubes-vm-update (and relevant core-admin-client parts), it will be quite a few places to change to use qubes.VMRootExec (and qubes.VMRootShell while at it) when needed. And it will need also to detect if the service is there (fortunately we have supported-rpc.* features).

[marmarek]

Alternative solution might be using sudo when sysmaint mode is detected. This might be less work, but feels dirty...

[ArrayBolt3]

Alternative solution might be using sudo when sysmaint mode is detected. This might be less work, but feels dirty...

It's also not guaranteed to work since the user may choose to password-protect the sysmaint account, which would deny sudo usage in an automated fashion without nopasswd exceptions.

[marmarek]

Yet another idea could be changing how force-user config option works, to not override dom0-selected root user. The root case is easy, but I'm not sure what would should be the behavior for other users (for example using qvm-run -u sysmaint .... or qvm-run -u user ...). Currently the VM always gets explicit user name, regardless if that's default user or explicit -u user, so it isn't easy to distinguish those cases. Note, if changing force-user behavior, it would affect all the services, not only shell/exec for qvm-run (and similar). I don't think it's widely used right now, but I can see users using this to redirect some services to a special service-related account.