These may seem excessive, but:
- 3 are for Go module version naming automation
- 1 is for kernel.org automation purposes
- 1 is for legacy consistency tagging
- 1 moving forward "official" tagging (packagers can use this one)
I've back-signed all of the libcap-2.xy releases with the "official" key:
$ gpg --fingerprint 0D23D34C577B08C4082CFD76430C5CFF993116B1
pub ed25519 2024-10-26 [SC]
0D23 D34C 577B 08C4 082C FD76 430C 5CFF 9931 16B1
uid [ultimate] Andrew G. Morgan (2024+ libcap signing key) <morgan@kernel.org>
sub cv25519 2024-10-26 [E]
Since the legacy tag uses a no longer considered secure technology,
I'll likely stop using it around libcap-2.75 when the new key has
gained more history and trust.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Starting with libcap-2.71 the following key is considered
the load bearing one on tags sig-libcap-2.xy:
0D23D34C577B08C4082CFD76430C5CFF993116B1
We'll back tag all of the libcap-2.* releases with the
corresponding signed tag.
Further, starting with libcap-2.72, we'll transition all of
the Go package tags (*v1.2.xy) to be signed with this key.
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>
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>
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>
I figured out that the key ingredient to reproducing this issue
was:
make COPTS="-D_FORTIFY_SOURCE=2 -O1 -g" clean test
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 occasionally test libcap against a custom kernel using QEMU.
Now I have a simple exit binary for exiting with status.
From the top level, one can use:
make ktest
However, for more control:
cd kdebug
make test
If you want to look around after the tests run:
make shell
Exit the shell & QEMU with ctrl-D (or exit).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Go has its own notion of major version, and this commit raises
it from 0 to 1. That is, these modules should now be considered
stable.
The sources for the 1.2.48 and the 0.2.48 modules are otherwise
identical.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Using naked make causes make to emit jobserver warning. So replace uses
of naked make with $(MAKE) to avoid these warnings.
Signed-off-by: Andrew Delgadillo <adelg@google.com>
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>
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>
I initially made one, and now modules are building with that stale
value v0.2.37. All despite the fact the Go modules are at v0.2.38.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It turns out that the Go module abstraction needs a tag specific to
each sub-package, and can't share a generic one for libcap as a whole
for both Go modules. As such, replace the vX.Y.Z tag with two
package/vX.Y.Z tags.
Signed-off-by: Andrew G Morgan <morgan@kernel.org>
Cleaned up the Go module redirection html file, now installed
at:
https://kernel.org/pub/linux/libs/security/libcap/
Note, I've moved the C source for libpsx.a into the psx/
directory, but the libpsx.a file is still built in the libcap
subdirectory as before. I also symlinked the C include files from
the psx/ directory. This made the source compile in conjuction
with the "psx" Go package automatically. It also substantially
simplified the go/Makefile.
I feel pretty good about this next version from the perspective
of a viable "psx" build. Caveat the need for CGO_LDFLAGS_ALLOW
on the command line pre-go1.15. Hopefully, the psx package comment
is enough for folk to figure that detail out.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It has been requested that we make the "libcap/cap" package into
a module that plays better with the golang ecosystem. I was holding
off until there was a golang version that contained the
runtime.AllThreadsSyscall() support, but that appears to not have
made it to 1.15, so I'm using a development build tag dependency
in otherwise static sources for the "libcap/cap" package.
My intention is that the canonical import paths for these packages
will be:
"git.kernel.org/libs/libcap/cap"
"git.kernel.org/libs/libcap/psx"
That being said, I may have to move them if I can't get some
proxy to resolve these paths to the right git repo of kernel.org.
The is work in the direction of addressing:
https://bugzilla.kernel.org/show_bug.cgi?id=207567
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The intended import path for this module is:
"git.kernel.org/libs/libcap/psx"
This is my first attempt at such module support, so it will
likely require some iteration.
This is work in the direction of addressing:
https://bugzilla.kernel.org/show_bug.cgi?id=207567
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Since we now have a serialized (linker trick) to initialize libcap
we can reliably compute the number of capabilities of the running
kernel in a race free way. Export the found number of capabilities
with the cap_max_bits() function. This is also what we now use in
both C and Go to define [all]=[eip]. In Go the equivalent function
is cap.MaxBits().
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Rewrote the pam_cap config file parsing to support:
- @group syntax for identifying groups of users
- ^cap_foo support for raising both inheritable and ambient caps
- !cap_bar support for dropping bounding capabilities
Updated documentation for pre-existing libcap's ambient support.
This pam_cap feature upgrade was done in collaboration with
Knut Omang and Christoph Lameter.
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>
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>
The API for this "libcap/cap" package is very similar to libcap.
I've included a substantial interoperability test that validate
libcap(c) and libcap/cap(go) have import/export text and binary
format compatibility.
My motivation for implementing a standalone Go package was for a
cross-compilation issue I ran into (Go is much more friendly for
cross-compilation by default, unless you need to use cgo).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The kdebug directory requires qemu to run and expects the kernel
to be compiled with the running architecture. My setup has the kernel
sources as a peer to the libcap directory so kdebug assumes that too.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I used to sign the .gz files with my old DSA key, but now will only be
signing the raw tar files with my kernel.org upload key.
Signed-off-by: Andrew G Morgan <morgan@kernel.org>
Also include a copy of the public key I have to use to upload binaries
to kernel.org. Moving forward, I plan to sign release tags with both keys.
Signed-off-by: Andrew G Morgan <morgan@kernel.org>
All the good parts of this change are Mike Frysinger's
<vapier@gentoo.org> work. Everything that is broken, is due to my
mangling of it.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Default is for make to guess if the user wants the module or not
user can override with
make PAM_CAP={yes|no}
Thanks to Chris Freidhoff for the suggestion and a first stab at a patch.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
