Discussion and explanation of what is up here is in:
https://bugzilla.kernel.org/show_bug.cgi?id=219169
This gets the Go cap package to parity with the recent changes to
libcap. This change will be live in cap/v1.2.71.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Pass the flags as they might be needed by $(CC) to properly compile or
link an executable (e.g. --sysroot).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Limit the conditions where we raise CAP_SETPCAP to set an IAB value.
There are some situations where that capability is needed, but they
are by no means a requirement for all IAB value setting.
Credit for discovering this goes to Christopher Head and reporting
it in:
https://bugzilla.kernel.org/show_bug.cgi?id=219169
Update the man pages to better reflect use of Amibient bit setting.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It looks like the Linux-PAM folk have deprecated this macro. Compiler optimization
is hard to account for: apparently this explicit deletion is no longer
guaranteed to work. This function was marked deprecated in v1.5.3 of Linux-PAM.
I've replaced its use with memset(). I'm not convinced that that will be honored
either, but remain hopeful and prefer to leave the code explicit in its intent
without a deprecation warning messing up the build log. Should some compiler
optimize it away and it leads to an exploit of some sort, it can be revealed as
a compilation bug.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Address user report of confusing behavior by adding a check to setcap
for a "<space...>" capability not meaning "-r".
Another suggestion from
https://bugzilla.kernel.org/show_bug.cgi?id=217592
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This change introduces the setcap -f argument to allow setting
of nonsense capabilities on files. But the default is to fail
when attempting to set such invalid capabilities.
This commit addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=217592
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Other than the case of /dev/null, there is no situation in which pam_cap.so
should act on world writable config files.
There are legitimate local administration choices for the file being owned
by non-root users, and similarly writable by a group of trusted users. So,
we do not require any specific ownership for the file and do not check for
writable access based on owner of group membership.
Credit for finding this bug in pam_cap.so goes to X41 D-Sec GmbH
(https://x41-dsec.de/) who performed a security audit of the libcap
source code in April of 2023. The audit was sponsored by the Open
Source Technology Improvement Fund (https://ostif.org/).
Audit ref: LCAP-CR-23-101
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The function pam_set_data() takes ownership of a memory pointer if
the call succeeds, but does not take that ownership if the function
fails. Previously, the failure caused no deferred capability setting and
a return code PAM_IGNORE. It continues to do that in this case, but no
longer leaks the allocated iab memory.
This bug was introduced with deferred IAB capability setting support in
libcap-2.58.
Credit for finding this bug in pam_cap.so goes to X41 D-Sec GmbH
(https://x41-dsec.de/) who performed a security audit of the libcap
source code in April of 2023. The audit was sponsored by the Open
Source Technology Improvement Fund (https://ostif.org/).
Audit ref: LCAP-CR-23-100
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Avoid something subtle with really long strings: 1073741823 should
be enough for anybody. This is an improved fix over something attempted
in libcap-2.55 to address some static analysis findings.
Reviewing the library, cap_proc_root() and cap_launcher_set_chroot()
are the only two calls where the library is potentially exposed to a
user controlled string input.
Credit for finding this bug in libcap goes to Richard Weinberger of
X41 D-Sec GmbH (https://x41-dsec.de/) who performed a security audit
of the libcap source code in April of 2023. The audit was sponsored
by the Open Source Technology Improvement Fund (https://ostif.org/).
Audit ref: LCAP-CR-23-02 (CVE-2023-2603)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This function returns a positive number (errno) on error, so the code
wasn't previously freeing some memory in this situation.
Discussion:
https://stackoverflow.com/a/3581020/14760867
Credit for finding this bug in libpsx goes to David Gstir of
X41 D-Sec GmbH (https://x41-dsec.de/) who performed a security
audit of the libcap source code in April of 2023. The audit
was sponsored by the Open Source Technology Improvement Fund
(https://ostif.org/).
Audit ref: LCAP-CR-23-01 (CVE-2023-2602)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Use type *id everywhere instead of using type * id and type* id
in some places. Also remove superflous spaces after commas, and closing
parentheses.
While doing this, I also fixed a C syntax mistake in an example in
cap_launch.3
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
There were a few straggler API functions in libcap and libpsx.
Also some functions that should be hidden from references outside
the library.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This code is investigating the issue:
https://bugzilla.kernel.org/show_bug.cgi?id=216610
This present commit extends x86_64 (aka amd64) support to 32-bit
arm build support. It is now possible cross compile the program
for the Raspberry Pi. To do this, the code needs 'docker' to work.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
When run via sudo, compare-cap exits with some file capabilities
left on its binary file. This is a test binary, so that's not a
big problem, however, it does mean that a 2nd run of the program
is started with, potentially, a different initial state.
This commit fixes that exit condition and addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=217018
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Increase the enforcement of the documented libcap API by marking
internal library utility functions as "hidden". This also goes
for the .so executable entry points.
This addresses this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=217014
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
While we test this in many other places, we didn't test this
explicitly in the psx.go local testing before. Now we do.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
If you have local files:
.../libcap/doc/local-md.preamble
.../libcap/doc/local-md.postscript
when you run .../libcap/doc/mkmd.sh these two files will be inlined
into the generated index.md file.
This addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=217007
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Explicitly add (void) as argument lists for two function definitions:
cap_reset_ambient(void)
_libcap_initialize(void)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
