$ 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>
I've upgraded one of my systems to Fedora 35 and I found trimming
the headers in this way made the three compilations of libcap, used
by `make distcheck`, work with standard Fedora 35 compiler packages.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The CGO_ENABLED=0 failure mode is discussed in:
https://github.com/golang/go/issues/50113
At the present time, this only passes when the psx package is compiled
CGO_ENABLED=1. The problem being that a blocking read cannot be
interrupted by the CGO_ENABLED=0 build of package "psx". It does not
deadlock when compiled CGO_ENABLED=1 because the psx signal wakes the
reading thread up back into user space.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Since libcap does some error testing with a pre-main() constructor,
reset errno to zero as that constructor returns.
Problem reported by Yang Xu.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
When a syscall that yields different return values is called from
the Go psx.Syscall*() API, we want to mirror the behavior of the
native golang runtime.AllThreadsSyscall() function.
The previous inconsistency was pointed out by Lorenz Bauer in:
https://bugzilla.kernel.org/show_bug.cgi?id=215283#c8
[I decided to defer this change until 2.63, and not include this
in the bug-fix for 215283, on the grounds it is a slight
incompatibility in runtime behavior, and wanted to give folk an
opportunity to plan for it. This new behavior enforcement will
crash an unprepared go program.]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This should complete the fix for:
https://bugzilla.kernel.org/show_bug.cgi?id=215283
Simplify the code, and add a test that the kernel has confirmed that
the thread is no longer running.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Lorenz Bauer found a race condition in the cap.Launcher teardown
process and reported it here:
https://bugzilla.kernel.org/show_bug.cgi?id=215283
This seems to significantly improve the situation. I'm going to
study the test case some more, but this is definitely part of the
solution.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
David Seifert at Gentoo made a request to not require perl for
the libcap build since their distribution wants to build it prior
to building perl and so requiring it requires they maintain some
extra patches.
We previously introduced the need for perl in response to some
apparent incompatibilities between various versions of sed:
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=9494a1fab59ac0b6e4f0bfc536fa482c6d6490b6
However, it has been 13 years since that time so we're optimistic
those problems are no longer present for anyone and we've also
added a make variable abstraction in case some builder wants to
override their system default 'sed' as make BUILD_SED=... etc.
We've also done something similar with make uses of grep, egrep
and fgrep.
Finally, for make variable naming consistency, we've replaced use
of BUILD_GPERF with USE_GPERF. Since folk may be using BUILD_GPERF
in their package building scripts, we error out if it is set.
The expectation is that people will update their package defs.
(Eventually, we plan to reuse BUILD_GPERF as an alias for 'gperf'.)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The previous commit crossed the beams on libpsx.so and libcap.so
executable build. This commit decouples them.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Mostly cause we can, but this gives a little more diagnostic
value to the libcap.so executable mode of operation.
usage: libcap.so [--help|--usage|--summary]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This function has been defined for a while (since libcap-2.30),
but I just found it wasn't documented.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Not sure where this will go, but libcap.so uses _libcap_initialize()
to set itself up at start up. So, run it when invoking libcap.so
directly as a binary.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
There seems to be a subtle difference between glibc and musl over
whether or not a runnable *.so needs to start out with its stack
aligned to 16 bytes or not. Since Linux ABIs for x86 (both 32 and
64 bit varieties) require 16 byte alignment, just force it on both
these architectures.
This addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=215009
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This was reported by Sam James and debugged with respect to:
https://bugs.gentoo.org/show_bug.cgi?id=820071
Modern versions of glibc employ SSE instructions that require the
stack to be aligned to 16 bytes in order to execute movaps and
friends to stack stored memory. The ABI for x86_64 requires this
alignment so we'd not seen this issue before being cc:d into the
bug.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This makes explaining how the program works more straightforward.
That is:
make CAPSO_DEBUG=-DCAPSO_DEBUG clean all
builds a version that prints out some helpful info and pauses so
the user can observe the capability state of the process tree at
different stages of execution.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I've been exploring the idea of how to create limited use privileged
binaries that can be linked into otherwise unprivileged binaries.
This is a worked example of the bootstrapping process for a webserver.
I intend to provide a more complete writeup of what is going on with this
example here:
https://sites.google.com/site/fullycapable/capable-shared-objects
For this present example to work you have to be using a libcap that
includes cap_launch support (ie., libcap 2.33+, but this code will be
included with libcap-2.61 and might inadvertently actually require
something that new to work robustly).
This code appears to be very fragile at present. It works on my
Chromebook's linux container, but not under Fedora 34 - segfaulting.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
