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>
We had somewhat inconsistent checks before, so this should cut
down on corner cases to worry about.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This API avoids a complex use case that requires substantially
more code outside of libcap.
Signed-off-by: Andrew G. Morgan <agm@google.com>
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
In 2.54 (*Set).Compare() was deprecated in favor of (*Set).Cf(),
so update the top level comment to reflect the preferred API.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Based on what I see on go.dev, there seems to be some preferred
comment style for deprecating a function. Use it to help spread
the word.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
We also add the cap.ProcRoot() API to let the user redirect to their
local /proc/ directory - in case anyone runs with an unusual setup
like that.
I've been studying the downstream package definitions and no one
it doesn't seem popular to build the Go packages. Indeed, Go folk
themselves prefer to install via modules anyway, so we're getting
with the program.
However, if folk want to build test the Go stuff as part of a package
build and run an install as well, we reward them with the 'captree'
binary.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Older APIs remain but are documented as deprecated. If we ever need
to release a golang version "2" version of the library, I'll drop
support for deprecated functions, but I have no intention of needing
to do that. In the mean time, the deprecated functions are wrappers
around the new functions.
New API: *Set and *IAB have .Cf() functions now. That return a
[IAB]Diff value. This value, if 0, means the compared pointers
match one another. Non-zero values can be interogated with the
([IAB]Diff).Has() functions.
Also, add an IABGetPID() function. Since the kernel provides no
syscall support for this, we have to resort to parsing the /proc/
files. Implemented mostly for parity with the syscall backed
GetPID() *Set returning API.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Slavi Marinov was asking about how a single webserver might use the
cap package to serve different content as a different user? So I
realized this detail wasn't obvious from the package documentation.
I also put together this example sketch:
https://play.golang.org/p/6Hr0XW3JP6a
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
We previously added a cap_iab_fill() etc, functions. Bring the
regular capability flag manipulation API into alignment by
adding libcap.cap_fill() and (*cap.Set).Fill().
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
A desire for this stabilization came out of a conversation with a
Google colleague, Mike Schilling.
This commit unifies the default libcap/cap (Go) behavior with libcap2
with respect to the binary output of cap.Export(). Previously,
libcap/cap.Export() could generate shorter binary values. [To restore
that behavior, set libcap/cap.MinExtFlagSize = 0.]
Looking to some point in the distant future, this also prepares libcap
to retain the same exported binary representation for capabilities
defineable today... That is, if the kernel were to extend the capability
flags to be 96 bits, but a capability of "cap_chown=ep" would not touch
any of the higher bits, an 'exported' capability in external format
should not need to change. (Setting libcap/cap.MinExtFlagSize = 0,
cap.Export() => 8 bytes for this capability set in external format.
However, libcap and libcap/cap now both default to 29 bytes. That is
libcap2 has the more significant legacy footprint.)
In all cases, libcap/cap and libcap2 were previously interoperable,
being able to import each others exported format. This remains true
[independent of the setting of libcap/cap.MinExtFlagSize].
Addresses this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=213375
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Ever wondered something like which capability allows a process
to do privileged things with a tty? Try this:
capsh --suggest="tty"
cap_sys_tty_config (26) [/proc/self/status:CapXXX: 0x0000000004000000]
Allows a process to manipulate tty devices:
- configure tty devices
- perform vhangup() of a tty
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>
A convenience feature, so you don't have to grep the
system header, and/or wade through a man page.
This addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=212451
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I'm going to return somewhat to what I had for the last release
but rename things to be a little non-standard in the hope people
notice a change has happened (albeit a content free one).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
My last attempt to placate the lawyers thwarted Go module automation.
License -> License.txt
LICENSE now mentions License.txt
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It can be difficult to use the syscall Prctl() with POSIX semantics,
so provide a function cap.Prctlw() that mirrors the call on all OS
threads of the runtime. cap.Prctl() is provided for convenience. It
should be used when reading state through the Prctl system call,
or when setting state that is naturally shared by the whole process.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Create a new launcher that does not require a specific target executable
but comes as close as Go lets to running code in a disposable security
context.
In C, this same functionality is implemented as a full blown fork() and
is useful when libcap is linked with libpsx. In Go, we can't
meaningfully fork the go runtime, so this is the next best thing. It is
intended to implement the feature discussed here:
https://bugzilla.kernel.org/show_bug.cgi?id=211919
Previously, we banned use of capability etc setting cap.Fn() calls from
within a launch callback. With this change, we now permit the callback
to perform cap.Fn() calls in such a way that they are automatically
limited to the callback goroutine and do not affect the rest of the
process. Because this goroutine will die after the launch callback
completes this behavior does not confuse the rest of the process - which
retains a process wide security state - POSIX semantics.
The main process goroutines outside of launchers will continue to block
on cap.Fn() calls that modify process capability state until all
outstanding launch()es have completed.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I realized that there was not explicit comments about this POSIX
semantics underpinning the behavior of libcap/cap. So, I've added some.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Reformatted the license files to capture the same info but
in a more clear way.
Note, I have migrated the license texts to "License" files
since, apparently, LICENSE files are picked up and parsed by
all sorts of automation that I don't want to reverse engineer.
The compiled binaries refer to said LICENSE file(s).
The default LICENSE files refer to the License files for
details. It is expected that folk that build against libcap
and friends, and need to choose one or the other license will
simplify their copies of LICENSE consistent with their own
needs and the scope explained in the License file(s).
All code distributed with the official libcap, unless
explicitly stated, is covered by the libcap License file.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
