* 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>
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>
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>
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>
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>
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>
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>
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>
