useradd/userdel with nss module if /etc/subuid or /etc/subgid exists

[AndersBlomdell]

Running this script:

#!/bin/sh

echo '## /etc/nsswitch.conf subid entry'
grep subid: /etc/nsswitch.conf

echo '## Working cases'

echo '# A. useradd, no /etc/subuid /etc/subgid'
rm -f /etc/subuid /etc/subgid
useradd -u 1000 -c DeleteMe -d /tmp/xxx -s /bin/nologin xxx
getsubids xxx

echo '# B. userdel, no /etc/subuid /etc/subgid'
rm -f /etc/subuid /etc/subgid
userdel -r xxx

echo '# C. newusers, with /etc/subuid /etc/subgid'
touch /etc/subuid /etc/subgid
echo 'xxx::1000::DeleteMe:/tmp/xxx:/bin/nologin' | newusers
getsubids xxx

echo '## Non-working cases'
echo '# D. userdel, with /etc/subuid /etc/subgid'
touch /etc/subuid /etc/subgid
userdel -r xxx

echo '# Cleanup non-working D'
rm -f /etc/subuid /etc/subgid
userdel xxx

echo '# E. useradd, with /etc/subuid /etc/subgid'
touch /etc/subuid /etc/subgid
useradd -u 1000 -c DeleteMe -d /tmp/xxx -s /bin/nologin xxx

Gives (where the maximal nss-module is similar to #819 ( shadow_subid_free method added):

## /etc/nsswitch.conf subid entry
subid:      maximal
## Working cases
# A. useradd, no /etc/subuid /etc/subgid
useradd: warning: the home directory /tmp/xxx already exists.
useradd: Not copying any file from skel directory into it.
0: xxx 65536000 65536
# B. userdel, no /etc/subuid /etc/subgid
# C. newusers, with /etc/subuid /etc/subgid
0: xxx 65536000 65536
## Non-working cases
# D. userdel, with /etc/subuid /etc/subgid
userdel: cannot remove entry 1000 from /etc/subuid
# Cleanup non-working D
# E. useradd, with /etc/subuid /etc/subgid
useradd: failed to prepare the new /etc/subuid entry

Since newusers handles that case, I guess duplicating want_subgids/want_subuids to useradd/userdel should be the preferred way?

[ikerexxe]

Thank you for reporting this issue. To better understand and reproduce the problem, could you please indicate at a high level what is the exact failure that you are seeing?

Additionally, I notice that your test scenario uses subid: maximal in the NSS configuration. However, maximal is not a supported NSS module for subid operations in shadow-utils. The supported NSS modules for subid are typically files and sss, but maximal is not among them.

[AndersBlomdell]

With an homegrown subid: maximal module (see #819),
I can't run useradd or userdel if any of the files /etc/subuid or /etc/subgid exists, if I delete them
things works as expected.

I.E. the affected programs don't honor the subid: entry in /etc/nsswitch.conf

[ikerexxe]

Running this script:

#!/bin/sh

echo '## /etc/nsswitch.conf subid entry'
grep subid: /etc/nsswitch.conf

What is the value of subid at this point? Can you indicate the shadow version you are using?

Can you briefly explain what's the problem you are encountering? There's a lack of context in the ticket and that makes it difficult to understand.

[AndersBlomdell]

shadow-utils-4.17.4-1.fc42.x86_64

It's for lab computers where logins come from a central LDAP server and where approximately 200 (of 35000) students will run various containers, and hence need subid's. The LDAP server does not give out subid's, so the simple solution
was to write a simple nss-module that gives all uid's between 1-65534 a calculated subuid/subgid range. That works well
until some user with root privileges decides to create /etc/subuid or /etc/subgid and then tries to add a new user (or delete an old one).

After reading the sources I found that newusers handled the presence of an nss-module, so I simply refactored that code
and copied it to the affected programs.

[ikerexxe]

I wanted to mention that I have some security concerns with the maximal NSS module.

Given that, it might be worth considering an alternative for a more robust long-term solution. The SSSD team is actively working on adding native subid support to their generic LDAP provider, and the work is expected to be merged into master soon.

• Upstream issue: Support subuid with generic LDAP provider SSSD/sssd#8030
• Active PR: LDAP: add subid ranges support SSSD/sssd#8057

The main consideration is that you'll need to use a distribution that includes this patch once it's released, and you will also need to adapt your LDAP schema accordingly.

Now, let me check the patch that you provided.

[AndersBlomdell]

I wanted to mention that I have some security concerns with the maximal NSS module.

Would be nice to know what concerns exactly.

Given that, it might be worth considering an alternative for a more robust long-term solution. The SSSD team is actively working on adding native subid support to their generic LDAP provider, and the work is expected to be merged into master soon.
...
The main consideration is that you'll need to use a distribution that includes this patch once it's released, and you will also need to adapt your LDAP schema accordingly.

Since I don't have control of the central LDAP-server or it's contents, I expect to have to live with my homegrown (maximail) nss-module for some time yet.

[ikerexxe]

I wanted to mention that I have some security concerns with the maximal NSS module.

Would be nice to know what concerns exactly.

Granting subuids to all users violates the principle of least privilege by giving them powerful but unnecessary permissions (you already mentioned that most of them won't need these permissions). This needlessly increases the system's attack surface, as a compromised account with a subuid range is a far more dangerous foothold for an attacker.

Furthermore, this practice maximizes the system's exposure to complex kernel bugs in the user namespace feature, where a vulnerability could lead to a full root compromise. Finally, it creates significant administrative complexity, making systems harder to audit and monitor while wastefully consuming the finite pool of system UIDs and GIDs.

[AndersBlomdell]

I wanted to mention that I have some security concerns with the maximal NSS module.

Would be nice to know what concerns exactly.

Granting subuids to all users violates the principle of least privilege by giving them powerful but unnecessary permissions (you already mentioned that most of them won't need these permissions). This needlessly increases the system's attack surface, as a compromised account with a subuid range is a far more dangerous foothold for an attacker.

Furthermore, this practice maximizes the system's exposure to complex kernel bugs in the user namespace feature, where a vulnerability could lead to a full root compromise. Finally, it creates significant administrative complexity, making systems harder to audit and monitor while wastefully consuming the finite pool of system UIDs and GIDs.

OK, that is what I already knew, and I consider the risk acceptable on those machines I use it on. Thanks!

[hallyn]

Hm,

Furthermore, this practice maximizes the system's exposure to complex kernel bugs in the user namespace feature, where a vulnerability could lead to a full root compromise

So long as user namespaces are enabled, a user can create a namespace where they map their own uid on the host to root in the namespace. Unfortunately, selectively giving subuids to only some users doesn't help with reducing the kernel api exposure.