Package: libpam-cap
Version: 1:2.25-2dxld1
Severity: important
Tags: patch upstream
Dear Maintainer,
libpam-cap is currently incompatible with the way 'sudo' handles
`pam_setcred`. If you look at the sudo source code in
`sudo_pam_begin_session` at plugins/sudoers/auth/pam.c:340:
if (def_pam_setcred) {
rc = pam_setcred(pamh, PAM_REINITIALIZE_CRED);
[...]
This is the only PAM_*INITIALIZE_CRED call in sudo. I did some digging
through the commit log and it seems some other platforms handle
PAM_INITIALIZE_CRED wrong and that's why sudo does things this way.
According to the (sparse) documentation on PAM I could find this
should work.
However libpam-cap has this in it's `pam_sm_setcred`
pam_cap/pam_cap.c:289:
if (!(flags & PAM_ESTABLISH_CRED)) {
return PAM_IGNORE;
}
which will skip the call to `set_capabilities` when sudo passes
PAM_REINITIALIZE_CRED. This prevents the code from applying the
capabilities from the config file as expected.
Since sudo only ever passes PAM_REINITIALIZE_CRED this obviously can't
work.
The fix is simple, just change the first line to
if (!(flags & (PAM_ESTABLISH_CRED | PAM_REINITIALIZE_CRED)))
I have been using a version of libpam-cap with the attached patch
applied for a while now and everything seems to work.
I also tried submitting this patch upstream with Andrew G. Morgan but
I think my either my mails aren't getting through and I couldn't find
a mailinglist or anything else so it's time to at least get this fixed
in Debian at least.
Thanks,
Daniel
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libpam-cap depends on:
ii libc6 2.28-10
ii libcap2 1:2.25-2
ii libpam-runtime 1.3.1-5
ii libpam0g 1.3.1-5
libpam-cap recommends no packages.
libpam-cap suggests no packages.
-- Configuration Files:
/etc/security/capability.conf changed [not included]
-- no debconf information
>From 7fe7190ae8f6944f54bc0dce628fec5804ca7724 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Gr=C3=B6ber?= <d...@darkboxed.org>
Date: Fri, 12 Apr 2019 22:47:38 +0200
Subject: [PATCH resend] Fix pam_cap ignoring PAM_REINITIALIZE_CRED
Some applications, such as sudo, only ever call pam_setcap() with
PAM_REINITIALIZE_CRED and expect this to have the same effect as
PAM_ESTABLISH_CRED on the first call.
Currently pam_cap simply ignores such calls causing inheritable capabilities
configured in it's config file not to be set when using such applications.
---
pam_cap/pam_cap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pam_cap/pam_cap.c b/pam_cap/pam_cap.c
index b1cc5cb..9813e71 100644
--- a/pam_cap/pam_cap.c
+++ b/pam_cap/pam_cap.c
@@ -286,7 +286,7 @@ int pam_sm_setcred(pam_handle_t *pamh, int flags,
int retval;
struct pam_cap_s pcs;
- if (!(flags & PAM_ESTABLISH_CRED)) {
+ if (!(flags & (PAM_ESTABLISH_CRED | PAM_REINITIALIZE_CRED))) {
D(("we don't handle much in the way of credentials"));
return PAM_IGNORE;
}
--
2.20.1
