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>
The function pam_set_data() takes ownership of a memory pointer if
the call succeeds, but does not take that ownership if the function
fails. Previously, the failure caused no deferred capability setting and
a return code PAM_IGNORE. It continues to do that in this case, but no
longer leaks the allocated iab memory.
This bug was introduced with deferred IAB capability setting support in
libcap-2.58.
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-100
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Avoid something subtle with really long strings: 1073741823 should
be enough for anybody. This is an improved fix over something attempted
in libcap-2.55 to address some static analysis findings.
Reviewing the library, cap_proc_root() and cap_launcher_set_chroot()
are the only two calls where the library is potentially exposed to a
user controlled string input.
Credit for finding this bug in libcap goes to Richard Weinberger of
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-02 (CVE-2023-2603)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This function returns a positive number (errno) on error, so the code
wasn't previously freeing some memory in this situation.
Discussion:
https://stackoverflow.com/a/3581020/14760867
Credit for finding this bug in libpsx goes to David Gstir of
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-01 (CVE-2023-2602)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Use type *id everywhere instead of using type * id and type* id
in some places. Also remove superflous spaces after commas, and closing
parentheses.
While doing this, I also fixed a C syntax mistake in an example in
cap_launch.3
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
There were a few straggler API functions in libcap and libpsx.
Also some functions that should be hidden from references outside
the library.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This code is investigating the issue:
https://bugzilla.kernel.org/show_bug.cgi?id=216610
This present commit extends x86_64 (aka amd64) support to 32-bit
arm build support. It is now possible cross compile the program
for the Raspberry Pi. To do this, the code needs 'docker' to work.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
When run via sudo, compare-cap exits with some file capabilities
left on its binary file. This is a test binary, so that's not a
big problem, however, it does mean that a 2nd run of the program
is started with, potentially, a different initial state.
This commit fixes that exit condition and addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=217018
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Increase the enforcement of the documented libcap API by marking
internal library utility functions as "hidden". This also goes
for the .so executable entry points.
This addresses this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=217014
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
While we test this in many other places, we didn't test this
explicitly in the psx.go local testing before. Now we do.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
If you have local files:
.../libcap/doc/local-md.preamble
.../libcap/doc/local-md.postscript
when you run .../libcap/doc/mkmd.sh these two files will be inlined
into the generated index.md file.
This addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=217007
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Explicitly add (void) as argument lists for two function definitions:
cap_reset_ambient(void)
_libcap_initialize(void)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It took me a while to figure out why optimized C compilation seemed
to generate miscomputation of the Fibonacci number sequence. It appears
to be an unresolved issue with Go's internal linking which is discussed
here:
https://github.com/golang/go/issues/24321
For a compute kernel, it seems important to be able to accommodate
compiler optimization. This adds some refinement for the strategy
I'm exploring to address:
https://bugzilla.kernel.org/show_bug.cgi?id=216610
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This example was developed while investigating the issues discussed in:
https://bugzilla.kernel.org/show_bug.cgi?id=216610
At this time, it is not possible to build CGO_ENABLED=1 and include
the "psx" package without using its "cgo"-tagged build variant.
This example provides a worked example of doing the opposite: link a
CGO_ENABLED=0 binary with "psx", including some compiled C code.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Günther Noack reported some issues with automated dependency checking in
https://bugzilla.kernel.org/show_bug.cgi?id=216609
Perhaps these additional lines will help assist those things.
I did find a typo in pam_cap/execable.c so I've fixed that.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This started out as addressing this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=216585
But I then made crosslink.sh to figure out what I had missed, and
fixed those bits too.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
There is a longstanding WONT_FIX bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=12491
that has been causing capsh, when linked fully statically,
to segfault. So, for non-dynamic linking of capsh etc utilities
only link statically to libcap. This way, in tree builds can be
guaranteed to get to execute with in tree API changes. For
normal installations, DYNAMIC=yes works as before.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This exploit code requires a make variable to activate, but
is used in the companion article discussing this code to compare
and contrast setuid-root to file capable privilege. Tl;dr don't
use setuid-root for shared libraries in this way!
Follow along here:
https://sites.google.com/site/fullycapable/capable-shared-objects
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
* GNU grep 3.8 considers `egrep` and `fgrep` obsolescent and throws warnings:
./mkcapshdoc.sh > capshdoc.c.cf
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
[...]
https://lists.gnu.org/archive/html/info-gnu/2022-09/msg00001.html
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
$ make
$ sudo go/captrace your-program
will attempt to explore what capabilities are needed to run
your program by observing when cap_capable() inside the kernel
is associated with your-program.
Other ways to invoke this are
$ sudo go/captrace --pid=<pid>
$ sudo go/captrace
The last of these traces everything running on a system.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Also down size the default capabilities needed by the 'sucap' su program.
This is aimed at addressing:
https://bugzilla.kernel.org/show_bug.cgi?id=215926
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I'm not 100% sure this is needed, but I'm not yet convinced
'make distclean && make -j48 test' works reliably, but I find this
easier to reason about.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Missed a vendor dependency for the ok.go file. More recent go releases
seem more picky about module or vendoring being used, and for the in-tree
builds we consistently use vendoring. So make sure the vendoring
directory set up has completed before trying to build ok.go.
The failure was reported by Tomasz Kłoczko.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This change adds support to capsh for the --noenv argument, which
will restore pre-libcap-2.65 behavior to capsh. The change we're
making here, however, is that capsh will now set the USER and HOME
environment variables when the command line contains --user=xxx.
The issue this addresses is described here:
https://bugzilla.kernel.org/show_bug.cgi?id=215926
This has been annoying me for long enough, and I want to clean up
the article:
https://sites.google.com/site/fullycapable/inheriting-privilege
to not pepper "--norc" in distracting places.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
