This bug, reported by David Runge, identifies another regression
vs. libpsx-2.71:
https://bugzilla.kernel.org/show_bug.cgi?id=219687
A regression of the LWP threading support reintroduced an old bug
in the libpsx-2.72 rewrite, specifically this bug:
https://github.com/golang/go/issues/42494
This present change includes x86_64, i386 and arm* (32-bit and 64-bit)
support. I've tested each of these with debian OSes, some running via QEMU.
Before releasing 2.74, I plan to extend the testing to all of the targets
supported by Debian (see https://wiki.debian.org/DebianInstaller/Qemu).
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>
This was a regresssion introduced in libcap-2.55. Fixed in libcap-2.59.
Added a cap_launch NULL test too. Comparing against NULL would cause a
SIGSEGV against these library revisions.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
* Respect user's CFLAGS/CPPFLAGS/LDFLAGS
* Respect $(MAKE)
* Remove CPPFLAGS from link rules
Note: for in-tree built test binaries, where we build --static,
we do not apply LDFLAGS: we want to limit external
dependencies in general; and users' LDFLAGS have a strong
tendency to conflict with --static for linking.
Work in collaboration with David Seifert (ie, he wrote most of it).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
As explained (thanks David Seifert) there are some LDFLAGS that
need to precede actual linked libraries. For example, -Wl,--as-needed.
Given this, I've tried it and it appears to work for the default
build cases as captured in 'make distcheck'.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Further observations from Zoltan Fridrich's static analysis of libcap.
This commit also includes a fix for something I broke with the last
round of "fixing", and a test to make sure I don't make that mistake
again.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
We're comfortable ignoring a write return code, but not all compilers
are so display a comment when the write in the uns_test fails.
This addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=214143
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The intention was to force --static linking in only one corner case,
so be more explicit about that one, and revert the build behavior
in the others.
Reason for doing this was feedback from Arnout Vandecappelle in:
https://bugzilla.kernel.org/show_bug.cgi?id=214023#c16
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
All credit for this fix goes to Samanta Navarro. The launch error
propagation code was evidently broken previously.
Samanta also provided a proof of concept test case and we've
included that in the tests/libcap_launch_test.c.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Discussion of one such setup in this bug (reported by David Runge):
https://bugzilla.kernel.org/show_bug.cgi?id=214023
Work around the failure to run ./pam_cap.so in these cases with
some more Makefile magic, and adjust test building with these
flags so it works in DYNAMIC=yes|no and SHARED=yes|no cases.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Tested with
make COPTS="-O2 -std=c89" clean all test sudotest
This addresses the issue reported by Byron Stanoszek:
https://bugzilla.kernel.org/show_bug.cgi?id=213541
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I found this corner case privilege escalation in December 2020.
Now that it is fixed upstream and widely deployed, add a test
so we don't regress.
[If you find 'make sutotest' fails for you, you should upgrade
your kernel.]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I seem to have omitted the callback test before, but now we have
cap_func_launcher() add some tests cases for it with and without
a binary to run.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Since I last visited securebits no privs mode, a new prctl bit
has been added (it isn't a securebit, but a parallel implementation
of something similar). So, layer that bit on top of NOPRIV mode.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=210135https://bugs.busybox.net/show_bug.cgi?id=13296
Some notes on expectations:
When building DYNAMIC=yes folk want to avoid depending on a
static libc.a file in their build tree. The best we can do is
to move building static test tool objects to sudotest.
make DYNAMIC=yes clean all test
will build the progs binaries and run the tests with all dynamic
linking. It will, however, build the libcap.a etc libraries too
even though they are not used for linking.
make DYNAMIC=no clean all test
will build the progs binaries and run the tests with all static
linking. It will, however, build the libcap.so etc libraries too
even though they are not used for linking.
make SHARED=no clean all test
will build and link progs and test binaries statically against
libcap.a. No shared libraries (libcap.so etc) will be built.
In all cases, whether linked against or not, libcap.a is built.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I've heard a number of folk ask why one might need libpsx for anything
other than Go program linking, so this demonstrates the class of exploit
that is possible when libcap is linked with -lpthread and not -lpsx.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Actually, fix the libcap_launch_test.c itself since it wasn't correctly
failing with an error exit code before.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
For now, the dynamic linkage of libpsx.so* is considered alpha.
The build tree supports it and can successfully run tests but
I'm hopeful I can get some feedback from third parties that it
works as expected.
Feature request:
https://bugzilla.kernel.org/show_bug.cgi?id=206093
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The static build of progs and tests, only needs the .a
libraries to be built.
Bug report from Thomas Petazzoni (trying to get capsh
etc to build against uClibc statically).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
make DYNAMIC=yes test sudotest
works now. Thomas Petazzoni provided a patch that built
the tests this way, but I've restructured things to
make the above command line work against the uninstalled
library builds.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
psx_test_wrap removed in
commit dca9b22261f4837b0c81640ca3aa5133b95e0999
Author: Andrew G. Morgan <morgan@kernel.org>
Date: Thu Jul 9 19:58:26 2020 -0700
Rewrite libpsx thread shutdown path to support musl.
Addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=208477
Removed the non-wrapping libpsx macro hacks. The API surface as such
becomes a little smaller and I now have confidence that wrapping
pthread_create using the linker options works with Go, gcc and musl
compilers. I feel it is stable enough to call good to delete the
workarounds.
Signed-off-by: Petr Ovtchenkov <ptr@void-ptr.info>
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=208477
Removed the non-wrapping libpsx macro hacks. The API surface as such
becomes a little smaller and I now have confidence that wrapping
pthread_create using the linker options works with Go, gcc and musl
compilers. I feel it is stable enough to call good to delete the
workarounds.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Apparently some folk like to supply these defines on the compiler
command line. Protect these defines with some more macrology.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
In threaded programs, it's a bit tricky to fork/execve a child with
capabilities different from the parent. Implement cap_launch and
friends to accomplish this.
https://bugzilla.kernel.org/show_bug.cgi?id=206195
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Linux supports three flavors of inheritable capability vectors:
- the I (inheritable set) of cap_t
- the A (ambient) alternative to file capabilities
- the B (bounding) vector.
The cap_iab_t collects these together into one object. I exactly equals
that of cap_t, A is what you would expect and B is "blocked" bits which
are ~cap_bound -- ie., 0 = nothing blocked.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
When we fork() we disable thread-shared semantics for
the psx_syscall()s of the child, but retain them in the
parent. This change also enhances support for unexpectedly
exiting threads (which seems to be the way Go likes to
terminate pthreads when using cgo linkage).
Enhanced licap_psx_test to fork() from created threads and
exit that thread after the forked child dies. (Ran this
10,000 times to generate confidence no races in libpsx.)
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>
The latter will invoke tests with sudo. Not all builds
can support this, but we do need a convenient way
to test this stuff...
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Also install the Go packages if built.
Remove a default behavior of installing an inheritable bit on setcap.
I'm getting alarmed that some distributions are setting the inheritable
set to full for all users. So, I don't want to provide a vector for
a trivial exploit, and hope they are not reinventing this:
https://sites.google.com/site/fullycapable/Home/thesendmailcapabilitiesissue
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Note, this override only supports the system calls that
libcap uses to change kernel state associated with the
current process. This is primarily intended to permit the
user to use libpsx to force all pthreads to mirror capability
and other security relevant state.
Use a weak function definition feature of libpsx share_psx_syscall()
to transparently arrange for libcap to so force itself to use the
psx_syscall() abstraction when linked against -lpsx. This has the
effect of using linker magic to make libcap transparently observe
POSIX semantics for security state setting operations. That is, when
linked as follows:
gcc .... -lcap -lpsx -lpthread -Wl,-wrap,pthread_create
all pthreads maintain a common security state with respect to the
libcap API.
This also adds full capability setting support to the Go package
libcap/cap via a libcap/psx package which uses cgo+libpsx syscalls
that share capabilities over all pthreads including those of the
Go runtime.
Finally, if Go supports syscall.PosixSyscall() etc. then provide
a non-psx mechanism for libcap/cap to "just work" in all Go code.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Since Linux kernel supported threads are not POSIX threads
and the glibc pthread library only supports POSIX semantics
for 9 system calls, to fully support the POSIX semantics for
a process sharing its security state across all of its
threads, we've created libpsx.
This commit also includes a threading test in tests/ for
this new psx_syscall() abstraction - one that transparently
mirrors calling POSIX-needing semantics syscalls over
all running threads.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
