| Age | Commit message (Collapse) | Author |
|---|
|
Other than the case of /dev/null, there is no situation in which pam_cap.so
should act on world writable config files.
There are legitimate local administration choices for the file being owned
by non-root users, and similarly writable by a group of trusted users. So,
we do not require any specific ownership for the file and do not check for
writable access based on owner of group membership.
Credit for finding this bug in pam_cap.so goes to X41 D-Sec GmbH
(https://x41-dsec.de/) who performed a security audit of the libcap
source code in April of 2023. The audit was sponsored by the Open
Source Technology Improvement Fund (https://ostif.org/).
Audit ref: LCAP-CR-23-101
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
|
While the session idea worked with contrib/sucap/su.c, it failed on
more traditional PAM apps. For a second (likely last) attempt to find a
path, I've deleted the session support and now attempt to do the setting
via a PAM data item cleanup() callback. In the contrib/sucap/su.c code,
evolved from the original SimplePAMApps 'su', there is a
pam_end(pamh, PAM_SUCCESS | PAM_DATA_SILENT)
from within the fork()d launcher code, so I hope this convention is
standard for all the PAM apps that came after.
The suggested config for this module for an app, that wants to support
the Ambient vector, is thus now:
#%PAM-1.0
auth required pam_cap.so keepcaps defer
auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so
This is all part of an effort to address:
https://bugzilla.kernel.org/show_bug.cgi?id=214377
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
|
This is an attempt to address:
https://bugzilla.kernel.org/show_bug.cgi?id=214377
The basic structure is you configure PAM with a config like this:
#%PAM-1.0
auth required pam_cap.so use_session keepcaps
auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so
session optional pam_cap.so
Here the "auth" part prepares the application with "keepcaps", and the
"use_session" instructs the module to apply any IAB tuple for the user
at session open time and not during the setcred (auth) flow.
This has been tested against the contrib/sucap implementation of su.
The "use_session" support should work with more standard PAM enabled
apps too, but I'll wait for some positive feedback (see the bug)
before declaring it stable.
FWIW the contrib/sucap/su app also supports this config for Ambient
vector setting (without a "session" invocation of pam_cap.so):
#%PAM-1.0
auth required pam_cap.so
auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so
session required pam_unix.so
but that is because the sucap/su app is more tightly integrated with
libcap than the standard PAM apps.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
|
This fixes a bug preventing 'make test' from working when invoked by root.
Bug reported by David Seifert:
https://bugzilla.kernel.org/show_bug.cgi?id=214257
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
|
Add a new optional argument to pam_cap.so. This argument substitutes
for a line like this in the capability.conf file:
<IAB> *
That is, it supplies the default <IAB> 3-tuple of capability vectors.
Any * value in the prevailing capability.conf file overrides this default.
However, the admin can supply arguments like this:
auth pam_cap.so autoauth config=/dev/null default=^cap_wake_alarm
to grant everyone who executes it the ambient capability cap_wake_alarm.
This addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=213611
However, see:
https://bugzilla.kernel.org/show_bug.cgi?id=212945
for issues limiting PAM application support for ambient capabilities in
general at present.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
|
We're not using it, but it seems like a small price to
pay for having targets I'm not building regularly
continue to build.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
|
Rewrote the pam_cap config file parsing to support:
- @group syntax for identifying groups of users
- ^cap_foo support for raising both inheritable and ambient caps
- !cap_bar support for dropping bounding capabilities
Updated documentation for pre-existing libcap's ambient support.
This pam_cap feature upgrade was done in collaboration with
Knut Omang and Christoph Lameter.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
