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>
go/captree was seeing lots of libcap_psx_test processes hanging around.
It turns out that the newly added _psx_cleanup() function was deadlocking
because inside a forked processes the psx_tracker.state was _PSX_INFORK
and never _PSX_IDLE.
This completes the fix for:
https://bugzilla.kernel.org/show_bug.cgi?id=215551
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It looks like various distributions are fairly far behind HEAD for
their version of libcap. This way folk can work around a lack of
features in their code.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It looks like go1.18 is going to default to CGO_ENABLED=0, so force
CGO_ENABLED=1 when building this cap-libcap comparison program.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=215603
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Kalen Hall reported that Valgrind detected a memory leak associated
with a multi-threaded program linked against libcap and libpsx.
https://bugzilla.kernel.org/show_bug.cgi?id=215551
I've been unable to validate this myself with valgrind (likely holding
it wrong), but did explore psx for allocated memory and via fprintf's
convinced myself that this change should pair all calloc()s with a
corresponding free().
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
