** Description changed: + [ Impact ] + + sudo-rs disregards PAM's account management for the internally managed + commands: + + * sudo -l / --list - list the user's allowed privileges + * sudo -e / sudoedit - edit files as another user + + Consequently PAM's account level policies are not respected for these commands, + allowing restricted accounts to still utilize sudoedit and --list. Do note that + this is not a privilege escalation bug; users still need to be granted this + access in the sudoers rules. + + The upload fixes this by moving the PAM check from `pre_exec` to before + the PAM context is returned, which allows the account level policies to apply + correctly. + + The justification for this fix is that the bug acts as a sort of blindspot for + administrators who expect accounts not to be able to perform these commands. + For instance, sudoedit would allow for editing a file as root even though the + PAM account policy should deny this. + + [ Test Plan ] + + Reproduce the bug + ----------------- + + * Assert that sudo-rs is the current sudo provider: + + sudo --version + + # Output: + # sudo-rs 0.2.13-0ubuntu1 + # ~~~~~~~ + + * Create a test user: + + sudo useradd -m -s /bin/bash resolute + + * Create a sudoers file that gives the user access to sudoedit (sudo -l is + given automatically): + + sudo echo "resolute ALL=(root) NOEXEC: sudoedit" > /etc/sudoers.d/test- + rule + + * Configure PAM account management for sudo by adding the following to + `/etc/pam.d/sudo`: + + auth include system-auth + account required pam_access.so + account include system-auth + + * Deny the test user by adding the following to + `/etc/security/access.conf`: + + -:resolute:ALL + + * Change to the user: + + su resolute + + * Verify that the user is still able to use sudoedit: + + sudoedit /etc/apt/sources.list.d/ubuntu.sources + + * Add a comment to the file (starts with '#') and save to complete + verifcation + + Testing proposed + ---------------- + + * Change back to the user with sudo access (the test user will be + denied) + + exit + + * Install the proposed sudo-rs: + + sudo apt install -t resolute-proposed rust-sudo-rs + + * Change back to the test user: + + su resolute + + * Verify that calls to sudoedit and sudo -l are denied: + + sudoedit /etc/apt/sources.list.d/ubuntu.sources + + # Output: + # sudo: PAM error: Permission denied + + sudo -l + + # Output: + # sudo: PAM error: Permission denied + + [ Where problems could occur ] + + * As the PAM check is moved to before `pre_exec`, it happens before the + session record is updated. This means that if a user is denied at this stage, + the session record will not include this denial. While this is arguably + an improvement, if anything external depends on the previous behavior, that + would now break. + + * A misbehaving PAM module may lead to users under certain PAM account policies + not being able to use sudoedit or sudo -l at all, even though they should be + able to. While this already affects other sudo commands, the upload would + now include sudoedit and sudo -l as well. + + [ Other Info ] + + * This SRU is part of a larger merge proposal for 26.04.1 + + * The fix is also natively part of the 0.2.14-1 upload to Stonking, currently + in proposed-migration + + [ Original Description ] + (Tracking bug from upstream: https://github.com/trifectatechfoundation/sudo-rs/issues/1613) This was submitted on 23 May 2025 by @thesmartshadow We consider the issue described below a non-compliance bug in sudo-rs (i.e. in a certain configuration the behaviour diverges). It can be summarised as that sudo-rs behaves as ogsudo with: ``` Defaults!sudoedit,list !pam_acct_mgmt ``` In /etc/sudoers. We have analysed this report carefully in the view of available documentation and PAM account modules: * The expectation of a sysadmin set by available documentation is important; many generic PAM account modules typically talk about "login access control", i.e. whether a user is allowed to access their account. It is not clear that this necessarily should limit the availability of `sudoedit` (and neither is this clearly specified in the sudoedit documentation). Furthermore, it is reasonable to expect that such generic modules also apply for the account as a whole and then a user wouldn't have easy access to `sudoedit`. * Of course there is a "persistence-after-revocation" possibility if an account expires while the user is logged in. But this presumes a user with malicious intent that at some point in time is logged in and has valid and permitted access to `sudoedit`, which essentially means a system is already compromised. * In the example of `pam_time`, a similar situation happens. We consider it bug that `sudoedit` doesn't listen to this policy, but to turn this into an attack implies having a user with malicious intent has privileges to `sudoedit` if they simply wait until the right time. * Other PAM account modules are of a type to configure access in a way that for sudo would be the non-obvious way to do things (for example, why would one use `pam_listfile` to specifically configure who can run `sudo`/`sudoedit` when `/etc/sudoers` would be the obvious place to do that).
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2160217 Title: PAM account-policy bypass in sudoedit permits unauthorized privileged file modification To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rust-sudo-rs/+bug/2160217/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
