This started out as addressing this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=216585
But I then made crosslink.sh to figure out what I had missed, and
fixed those bits too.
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>
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>
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>
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>
The flag --quiet causes capsh to suppress its startup check that
the linked libcap has support for all of the named capabilities
of the hosting kernel.
The cap_launch() support is via "-+" and "=+" arguments. These use
cap_launch() to fork() before exec*()ing the corresponding command
but are otherwise equivalent to "--" and "==" respectively.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Modify the cap_launch() behavior when chroot is set. Now, the
launcher code will force the post chroot() environment to
chdir("/").
Modify the API for many of the cap_launch_*() functions that
previously were void, to returning int (0=OK, -1=see errno).
I'm confident that this should be code backwardly compatible,
since the return values are new and prior code would have been
assuming success.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Embed mutex locked operation into the IAB API. The idea being that
while libcap operates on an IAB tuple, it cannot be operated on by
a thread running in parallel. This makes IAB access thread safe (but
not reentrant).
The only potential API behavioral change is that the IAB tuple
associated with a cap_launcher_t is now locked for the duration of
its association with that launcher. This prevents a race condition
with launching and another thread changing that IAB tuple.
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>
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>
Up to this point, capsh hides some complexity concerning raising
the CAP_SETPCAP in order to raise inheritable and drop bounding
set values. This made it harder to explain some aspects of
inheritance, and I ran into that detail writing this:
https://sites.google.com/site/fullycapable/why-didnt-that-work#h.z7rwbcazhr4r
Refactored capsh.c to clean up some buggy code, and also fix some
documentation, including reference to the --strict argument.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This brings libcap back to parity with the Go 'cap' package. We
provide a CAP_IAB_DIFFERS(result, vector) macro to evaluate the result
of cap_iab_compare().
Extend the getpcaps arguments to include --iab. This causes the utility
to explore the IAB tuple for the specified process. When used, this
outputs a text representation in a similar format to that of the
'captree' (Go) utility.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This is equivalent to 'capsh --print|fgrep Current'. I've been using
that combination a lot in the write-ups on the libcap website
(https://sites.google.com/site/fullycapable/) and so it struck me
that capsh probably should support it natively.
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>
In an effort to help folk contribute to the discussion around
existing bugs, and benefit from recently closed ones, update the
main library man pages with better direction towards recent info.
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>
Some PAM applications drop privilege when they change UID, which has
the side effect of dropping ambient capabilities. We add support for
the "keepcaps" argument which can be used in an attempt by the module
to not drop permitted capabilities when performing a setuid() call.
Some experimentation may be needed to see if this works for any given
application. To not be a security bug vector, it requires the application
so configured perform an exec() to launch a user-specific operation.
This is an attempt to provide some Adminstrator support for working
around the issue observed in this bug (report by Zoltan Fridrich):
https://bugzilla.kernel.org/show_bug.cgi?id=212945
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>
This addresses the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=209873
Namely, the following didn't previously work:
PATH=/sbin capsh == --print
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Also, improve the "cap" package documentation to give an overview
of its text representation support.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
