Bug 1150522

Summary:	AUDIT-1: libcap: review pam_cap not yet whitelisted in rpmlint
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Matthias Gerstner <matthias.gerstner>
Component:	Security	Assignee:	Malte Kraus <malte.kraus>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	jsegitz, malte.kraus, matthias.gerstner, meissner, tiwai
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Bug Depends on:
Bug Blocks:	1150178

Description Matthias Gerstner 2019-09-12 10:50:25 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
catch them.

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
rpmlint.

Comment 1 Malte Kraus 2019-09-19 13:00:10 UTC

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?

Comment 2 Takashi Iwai 2019-09-23 15:16:22 UTC

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.

Comment 3 Matthias Gerstner 2019-12-16 13:18:38 UTC

(In reply to tiwai@suse.com 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?

Comment 4 Takashi Iwai 2019-12-16 13:25:53 UTC

I really do care little about this package, so I'd love to leave this you guys...