Bugzilla – Bug 1150522
AUDIT-1: libcap: review pam_cap not yet whitelisted in rpmlint
Last modified: 2022-02-28 07:15:04 UTC
+++ This bug was initially created as a clone of Bug #1150178
As discussed in the proactive security team we want to catch up on the packages
shipping PAM modules that haven't been reviewed yet. Formerly there was no
badness for this type of rpmlint check. Right now the new review bot should
libcap is one of the packages shipping a pam module (pam_cap) that has not
been reviewed yet.
The code should be checked and if all is well a whitelisting be added to
So, to me this thing just seems like a bad idea all-around.
It allows configuring capabilities that are granted through PAM to users when they log in. Since nearly all capabilities are equivalent to full root access, it's much easier to just log in as root and be done with it, instead of logging in as a user and pretend to have some sort of security. But the default configuration is safe (only removing capabilities), so it could be argued that insecure (~all) usage of pam_cap is the admin's fault, not ours.
Looking at the implementation, it modifies the capabilities of the current process in pam_setcred(). However, it doesn't implement the PAM_DELETE_CRED flag to revert the capabilities when a user session ends. As a result, processes that used PAM to do something as a user will keep on having these capabilities even when the user context has long ended. From a quick survey of random user's of PAM, there's a whole lot of long-running daemons calling pam_set_cred when using PAM for authentication that definitely never should be receiving a capability. (And they very rarely call PAM_DELETE_CRED when they're done.) Again, I guess the only excuse is that it's the admin's fault for configuring pam_cap for such services instead of limiting it to specific interactive login sessions.
Overall, I see a whole lot of risk and have trouble thinking of a single valid use-case. Takashi, how do you feel about removing this PAM module from Tumbleweed and future releases?
That sounds like a fair argument, and I don't know (actually care little) about this pam module at all.
Could you go ahead and trigger disablement? I'll be traveling from this week for the next few weeks, so I cannot work on it. Thanks.
(In reply to firstname.lastname@example.org from comment #2)
> Could you go ahead and trigger disablement? I'll be traveling from this
> week for the next few weeks, so I cannot work on it. Thanks.
It seems this change got lost over the months. Could you do this now for us?
I really do care little about this package, so I'd love to leave this you guys...