Page MenuHomePhabricator
Create Task
Maniphest T1001

Updates proxy check fails in whonix-ws-15
Closed, ResolvedPublic
Actions

Description

Recent test runs report failure of whonixcheck, I think relevant lines:

Jan 05 02:51:27 host sudo[1882]: pam_exec(sudo:auth): /usr/lib/security-misc/pam-abort-on-locked-password failed: exit code 1
Jan 05 02:51:27 host sudo[1882]:     root : PAM authentication error: System error ; TTY=unknown ; PWD=/ ; USER=updatesproxycheck ; ENV=UWT_DEV_PASSTHROUGH=1 ; COMMAND=/usr/bin/curl --silent http://127.0.0.1:8082/
WARNING: Execution of /usr/bin/apt-get prevented by /etc/uwt.d/40_qubes.conf because no torified Qubes updates proxy found.

The exact command is: qvm-run -ap whonix-ws-15 'LC_ALL=C whonixcheck --verbose --leak-tests --cli'
Full output: https://openqa.qubes-os.org/tests/15305/file/whonixcheck-whonixcheck-whonix-ws-15.log

This may be related to not setting empty root password anymore.

More info extracted from logs:

[2021-01-04 21:51:10] [   16.144317] torified-updates-proxy-check[538]: + true
[2021-01-04 21:51:10] [   16.146402] torified-updates-proxy-check[538]: ++ sudo -u updatesproxycheck UWT_DEV_PASSTHROUGH=1 curl --silent http://127.0.0.1:8082/
[2021-01-04 21:51:10] [   16.226376] sudo[629]: pam_exec(sudo:auth): /usr/lib/security-misc/pam-abort-on-locked-password failed: exit code 1
[2021-01-04 21:51:10] [   16.226983] torified-updates-proxy-check[538]: /usr/lib/security-misc/pam-abort-on-locked-password failed: exit code 1
[2021-01-04 21:51:10] [   16.230002] torified-updates-proxy-check[538]: sudo: PAM authentication error: System error
[2021-01-04 21:51:10] [   16.231315] sudo[629]:     root : PAM authentication error: System error ; TTY=unknown ; PWD=/ ; USER=updatesproxycheck ; ENV=UWT_DEV_PASSTHROUGH=1 ; COMMAND=/usr/bin/curl --silent http://127.0.0.1:8082/

Looks like /usr/lib/security-misc/pam-abort-on-locked-password prevents root from using sudo (if there is no root password set). Since torified-updates-proxy-check is started as root (systemd service?), perhaps sudo usage is not needed there and simple runuser or even setpriv would be enough?

Details

Impact
Needs Triage

Event Timeline

marmarek created this task.Jan 5 2021, 5:03 AM
Herald added a project: Whonix. · View Herald TranscriptJan 5 2021, 5:03 AM
Herald added subscribers: • entr0py, Patrick. · View Herald Transcript
marmarek added a project: bug.Jan 5 2021, 5:03 AM
Patrick added a comment.Jan 5 2021, 6:07 AM

/usr/lib/qubes-whonix/init/torified-updates-proxy-check is currently only started by /lib/systemd/system/qubes-whonix-torified-updates-proxy-check.service.

Wondering why this is happening. When root uses sudo, pam shouldn't even be involved.

Would also be good if the whole script would run as non-root. However, it needs to write into /run/qubes-service/ folder.

This may be related to not setting empty root password anymore.

When/where/how was this changed? Or how can I reproduce setting the same root password that Qubes is using now? I.e. how/where is it being done now during the build process / package maintainer scripts?

marmarek added a comment.Jan 5 2021, 5:54 PM
In T1001#20201, @Patrick wrote:

/usr/lib/qubes-whonix/init/torified-updates-proxy-check is currently only started by /lib/systemd/system/qubes-whonix-torified-updates-proxy-check.service.

Wondering why this is happening. When root uses sudo, pam shouldn't even be involved.

PAM is involved always when something needs user authentication, including root. But there may be a PAM configuration bypassing it for root. For example /etc/pam.d/su has this quite early:

# This allows root to su without passwords (normal operation)
auth       sufficient pam_rootok.so

But I don't see similar bypass for sudo in Debian.

Would also be good if the whole script would run as non-root. However, it needs to write into /run/qubes-service/ folder.

Well, since it needs to switch to another user to run curl, it also needs some kind of extra privileges (here with sudo, which is now broken).
As for /run/qubes-service/, I think it's quite arbitrary, since whonix-secure-proxy isn't really controlled via qvm-service framework, it is just a file created by torified-updates-proxy-check and then checked by another script. Theoretically it can be anywhere. But indeed some location in /run is convenient here.

Anyway, since the script is started by systemd unit only, maybe the whole script can be started by systemd as updatesproxycheck user, removing the need for sudo or any other mechanism? And then the flag file put in a (new?) directory where updatesproxycheck user could write?

This may be related to not setting empty root password anymore.

When/where/how was this changed?

https://github.com/QubesOS/qubes-issues/issues/5799

Or how can I reproduce setting the same root password that Qubes is using now? I.e. how/where is it being done now during the build process / package maintainer scripts?

Now root password is simply not set, so it remains locked (! in /etc/shadow).

marmarek added a comment.Jan 8 2021, 2:28 PM

I've found why sudo asked for password, it wasn't related to security-misc script mentioned earlier. And should be fixed in newer qubes-core-agent package.

But I think it's still a good idea to not rely on sudo in systemd service.

Patrick added a comment.Jan 9 2021, 6:43 AM

https://gitlab.com/whonix/qubes-whonix/-/commit/53ff72ab6ce59cb2c98401fd701ae782ca100e37

Patrick closed this task as Resolved.Jan 24 2021, 11:08 AM
Patrick claimed this task.

Btw this issue tracker is being phased out:
https://www.whonix.org/wiki/Reporting_Bugs#Issue_Tracker

Whonix OLD Issue Tracker · PLEASE DO NOT POST NEW TICKETS HERE · OLD Issue Tracker - Unread Notifications · OLD Issue Tracker - Feed · OLD Issue Tracker - Open Issues · NEW Issue Tracker · Homepage · Blog · Forum · Legal · Imprint · Privacy Policy · Terms of Use · Disclaimer