pam_groups (/etc/security/group.conf) is ignored

[staeglis]

Describe the bug
So far we use /etc/security/group.conf to map AD users and groups to the local sudo group. This worked with the original sudo implementation but not with sudo.rs

To Reproduce
Steps to reproduce the behavior:

1. Enable pam_groups
2. Map user $testuser to sudo group via /etc/security/group.conf
3. Start new session as user $testuser
4. run sudo command, e.g sudo -i

Observed behavior

$ sudo -i
sudo: I'm sorry $testuser. I'm afraid I can't do that

Expected behavior
sudo should ask for password

Environment (please complete the following information):

• Linux distribution: [Ubuntu 26.04]
• sudo-rs version [sudo-rs 0.2.13-0ubuntu1]

Additional context

[squell]

Thanks for the report! Does this also happen with 0.2.14? Tarball: https://github.com/trifectatechfoundation/sudo-rs/releases/download/v0.2.14/sudo-0.2.14.tar.gz

[staeglis]

Yes this also happens with 0.2.14

[squell]

Thanks for checking, I wanted to make sure it's not a duplicate of #1572.

The issue is probably that we run the PAM authorization stack after consulting the policy module. One solution for that would probably be to run the PAM-auth stack also in case of a policy rejection and re-check the policy if any of the credentials changed. That could also offer something for #1659 since after that point, even if the authorization is still not present, showing the output of sudo --list would be fine.

But it's something to be discussed with the rest of the team because it does make the authorization pipeline a bit more complex.

[bjorn3]

If the policy depends on the authentication stack running, wouldn't this mean there is a cyclic dependency? Say you have a sudoers file which says everyone in the foo group is NOPASSWD, but the current user is only know to be in the foo group after running the authentication stack. Then running the authentication stack before checking the policy would incorrectly ask for the password (as NOPASSWD in the policy should skip the authentication stack), but running the authentication stack after checking the policy would also incorrectly ask for the password as we don't know the user is in the foo group and thus has NOPASSWD.

In any case it looks like pam_group sets the groups in pam_setcred, not pam_authenticate: https://github.com/linux-pam/linux-pam/blob/dd74fc113a9ba1f94d5469f6f7857a1884b3f550/modules/pam_group/pam_group.c#L828 And og-sudo runs pam_setcred right before pam_open_session, which is long after evaluating the policy. I don't see how /etc/security/group.conf could have had any effect on the policy with og-sudo too. Are you sure you only use /etc/security/group.conf and not also say the LDAP plugin of og-sudo or the netgroups functionality?

[staeglis]

Yes I'm sure

[squell]

If the policy depends on the authentication stack running, wouldn't this mean there is a cyclic dependency? Say you have a sudoers file which says everyone in the foo group is NOPASSWD, but the current user is only know to be in the foo group after running the authentication stack. Then running the authentication stack before checking the policy would incorrectly ask for the password (as NOPASSWD in the policy should skip the authentication stack)

A circular paradox isn't that unusual for sudo. There are various ways in ways (og)sudo can tie itself into a knot theoretically but then simply cuts that knot, ex.:

Defaults:aDmiN !case_insensitive_user

Should a user called "admin" be matched case insensitively or case sensitively in the sudoers file?

Defaults!/usr/bin/ls secure_path=/sbin

Should "sudo ls" then resolve to "/usr/bin/ls" or not?

I don't see how /etc/security/group.conf could have had any effect on the policy with og-sudo too. Are you sure you only use /etc/security/group.conf and not also say the LDAP plugin of og-sudo or the netgroups functionality?

Obviously step 1 would be to see if we can reproduce this in a small docker; given the description that should be doable without the full AD setup.

I can also very well imagine that this is a scenario where we can simply decide to document the differences with ogsudo (but then at least we should document it).

[squell]

@staeglis Am I correct in assuming that you're using sudo 1.9.17p2 as a comparison? I've tried to follow the steps in a Debian sid docker, i.e.:

• add pam_group.so in /etc/pam.d/sudo-i
• map a user to a group configured to have sudo access in /etc/sudoers via /etc/security/group.conf:

sudo-i;*;user;Al0000-2400;sudo

• run sudo -i --> "user is not in the sudoers file."

I've focussed here on the "sudo -i" example since that was in your example (which uses the sudo-i PAM service name for both ogsudo/sudo-rs)

What I can see is that the group added by pam_groups doesn't end up in the actual user groups, e.g.

# sudo -i -u user groups
user sudo

whereas with sudo-rs I just see:

# sudo -i -u user groups
user

Which feels like it could be related to your issue.

Potentially related PR: #1062

[staeglis]

We use pam-auth-update to enable the module. When run the sudo command with the og-sudo (versions depends on the distribution) all groups listed in group.conf are added.

We start using this at least with Ubuntu 18.04 and it always worked until the latest Ubuntu/Debian but not with sudo-rs.

In our case the group.conf would be

*;*;user;Al0000-2400;sudo

[squell]

Thanks! For now the workaround for your use-case is to keep using ogsudo using update-alternatives (even once fixed, it's not up to us if this gets a Stable Release Update). For us this is an interesting issue to look into.

Since you have *;*;user;Al0000-2400;sudo and use pam-auth-update, I would expect the groups pam_groups adds to be already added by a PAM stack before sudo even starts, since it would be added to common-auth. (E.g. when a user simply logs in locally, or logs in with SSH assuming UsePAM yes is set, etc. etc.). So some further questions:

1. Isn't sudo already listed as part of the groups for user when the groups command is used?

2. It could also help us to have a more precise idea of there are other site-specific modifications to your /etc/sudoers file to rule out the possibility that the policy rejection stems from a combination of factors. I can understand you might not want to dump that on a public forum such as here, but if it is heavily modified free to mail it (that could be sent to security+sudo@trifectatech.org, if needed it can be encrypted with the key listed our SECURITY.md)

[staeglis]

1. Yes the group is already listed before running sudo
2. We just use the default configuration

[squell]

That was exactly the remaining necessary info. I've been able to reproduce locally.

I've analysed this with @rnijveld and found two issues:

1. We load the current user via the ordinary User interface, which fetches the groups using getgrouplist(). That only looks at groups defined in /etc/groups. If one uses getgroups(), the ones added by pam_group.so are loaded properly. So I think the fix can simply be to alter the CurrentUser datatype we have to (re)load the current groups with getgroups() instead. That should be simple to implement, and be enough to close this issue.

2. The other issue I alluded to above is not part of the original report and can be ignored. FWIW, the reason is that any groups in /etc/security/group.conf are not added by sudo-rs because these are set by pam_setcred(), but we perform setgroups() later, right before command execution. Related is this entry in ogsudo's changelog from 2016-04-28:

    * src/sudo.c:
   Do group setup in policy_init_session() before calling out to the
   plugin. This makes it possible for the pam_group module to change
   the group in pam_setcred(). It's a bit bogus since pam_setcred() is
   documented as not changing the group or user ID, but pam_group is
   shipped with stock Linux-PAM so we need to support it.
   [f88da1c1a]

I think this is a less pressing issue: as Todd mentions, this essentially violates the user contract for pam_setcred(), the actual use cases for this are pretty exotic, and it is a change that cuts right through our auth pipeline... Anyway, I will open an enhancement issue for it. (Edit: see #1665)