ID: 1001PHID: PHID-TASK-2dxobbn6uq2ox5bq3dcuAuthor: marmarekStatus at Migration Time: resolvedPriority at Migration Time: Needs Triage
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'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?
2021-01-05 06:07:18 UTC
/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?
2021-01-05 17:54:50 UTC
! 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)./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?
Cleanup root password setting, logging on xl console and related stuff · Issue #5799 · QubesOS/qubes-issues · GitHub
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).
2021-01-08 14:28:09 UTC
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.
2021-01-09 06:43:58 UTC
2021-01-24 11:08:04 UTC