-
Notifications
You must be signed in to change notification settings - Fork 228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for ambient capabilities #408
Conversation
You seem to be saying that pam_cap.so by itself isn't able to give you the pI you specify in capabilities.conf, and therefore you need to set KEEPCAPS in login.c. Is that what you are finding? I think it would be better to add ambient capability support to pam_cap.so and leave all that logic out of su and login, if possible. |
Leaving this to pam_cap.so entirely, will not work. Please, let me explain: Ambient capabilities will not survive the setuid() system call. To support ambient capabilities, one has to save the ambient caps before calling setuid() and restore them after that. Calling setuid() is the most important thing the login and su applications do. There is no way to delegate this to pam_cap.so. The keepcaps flag is different. This flag is thread specific and has to be set via prctl(). The flag must be set with root privileges and survives the setuid() call but it won't survive execve(). Without the keepcaps flag set it is not possible to restore the ambient caps after the setuid() call. So, specifying ambient capabilities in capabilities.conf, will grant these capabilities to PAM clients up to the moment they call setuid(). With ambient caps not surviving setuid() and the keepcaps flag not surviving execve(), supporting ambient capabilities naturally fall in the scope of login and su. |
Yes, I see. Ideally there would be a pam_* helper called after the setuid() in which pam_cap.so could re-set the pA. |
There seem like there are two aspects to this pull request:
For (1), is there some reason that the For (2), In the proof of concept example I worked up here: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/contrib/sucap I used the https://bugzilla.kernel.org/show_bug.cgi?id=214377 to explore if |
So this will be included in libcap-2.58 (plus any bug fixes I accumulate before then): Let me know if it works for you:
|
As I like this approach very much to keep everything within the PAM layer, this does not work without further modifications:
This should not be changed, I think. The man page PAM_OPEN_SESSION(3) suggests that the calling application should have sufficient privileges to perform tasks like creating or mounting the user's home dir. Calling ¹Seems to have quite a paper trail. |
That is, indeed, a pity. I have one more idea before giving up on this. |
My work here should be done. Specifically, comment 3 here: Use the same instructions for downloading and building the module (or This attempt is based on the Linux-PAM documentation for application writers (I have some vague recollection of writing those words about 20 years ago...!), so if this doesn't work, I think there is some sort of problem with the application: This latest
If the app doesn't do this, then that's a deviation from that documentation, and that's a PAM API fix the app can make... |
Indeed. Looking at the missing call to
|
Great idea to put it into the cleanup code path. Confirmed to work with So, thanks to Andrew's excellent work, my pull request basically collapses to:
|
Taking into account that there's a commit that reverts another one I think that you should squash everything in one commit. |
How do I do that? Preferably |
I'd use For more information you can check: https://levelup.gitconnected.com/how-to-squash-git-commits-9a095c1bc1fc |
aeacf82
to
ac938b2
Compare
There might be some issue left to explore... Expanding the diff for that patch for
I don't know how old that comment is, but clearly there was some concern that it didn't work reliably at the time it was written. I'd argue that this is some sort of distributed non-compliance problem if it still exists. I plan to stick with this support expectation in |
Looks like it was introduced in 2007 by commit 0fd1ed4 to address https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412061 |
Does not look that well. pam_krb5 still does not implement |
FWIW I just released libcap-2.58. |
The pam-krb5 commit should have resolved this issue with that module. |
Awesome. Can you confirm (Björn) that, and explain why, the commented-out location is |
In fact, the added location of |
ac938b2
to
97f788f
Compare
Ok, I have used the patched version for some time now on my production workstation and laptop, and I explored a few different PAM setups at my university. Seems to work as intended. Anything left to do before merge? |
I was trying this out and it did not work for me. I took fedora version of libcap, patched it with keepcaps and defer commits from libcap upstream. Then I took shadow-utils patched with this PR and installed both these modified packages. I set /etc/security/capability.conf to @bjorn-fischer @AndrewGMorgan Am I doing something wrong? |
[...]
This usually happens if the application performing the login procedure misses the |
@ZoltanFridrich When tracing
This was the call to fork(), now looking for PID 21167:
After this, no |
@ZoltanFridrich I suspect your |
I dug in a bit more. On Fedora-34,
It too is non-compliant and the needed patch looks something like this:
I've forwarded a copy of that patch to the author of the most recent Changelog entry here: https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.37/v2.37-ChangeLog |
Just in case, informing @karelzak maintainer of util-linux |
Thanks for your info. It seems, the most important thing is PAM_DATA_SILENT -- I hope it's correctly implemented in PAM, because everywhere (in util-linux login and su) we keep the parent process running to clean up the session later. We have to be sure that after pam_end() in the child the PAM handler is still valid in the parent. AndrewGMorgan and bjorn-fischer, please, please, can you also prepare PR for util-linux for login-utils/su-common.c and login-utils/login.c. I guess it's not only Fedora who uses login and su from util-linux. It's a trivial patch, but I'd like to be sure it's tested by someone who has experience with ambient capabilities. Thanks! |
@AndrewGMorgan @bjorn-fischer so just to make sure, this patch is good to merge? |
This looks good to me. However, the tabbing for the added code might need some attention to be consistent with the code it is being added to. |
This conforms to PAM documentation and it is needed to support ambient capabilities with PAM + libcap-2.58+. Signed-off-by: Björn Fischer <bf@CeBiTec.Uni-Bielefeld.DE>
Thanks, I went ahead and made that change, so am merging now. |
- Update from 2.50 to 2.61 - Update of rootfile - Changelog Release notes for 2.61 Better error handling of the numerical arguments for capsh and setcap. Reported by meitingli with some bug de-duping help from Artem S. Tashkinov (Bugs 214909, 214911) Fix executable mode for all of the .so files. There were two situations where this was failing (with a hard to debug SIGSEGV inside libc). Bugs reported by Sam James. Both the same solution related to stack alignment and use of SSE instructions: glibc and the 32-bit x86 mode (Gentoo bug 820071) musl runtime library for 64-bit x86 code (Bug 215009) Added an example of a shared library object with its own file capability. It demonstrates how to give a shared library a file capability and offer it as a linkable privileged API service to an otherwise unprivileged binary. Fix the top-level include for Make.Rules in the contrib/sucap example application Add support for running constructors at libcap.so start up time when running as stand alone binary. This enables the binary executable to print out some dynamically generated content when given the --summary argument. Release notes for 2.60 Some build, code linting fixes, the addition of the cap_fill_flag() API and a memory latency optimization contributed by Google (Bugs: 214579 214601 214599) General improvement in thread safety for libcap and cap package (Bug: 214715) Minor API change replacing libcap:cap_launch_*() void returning functions with int + errno status returns. This should be backwardly compatible for code. Added a cap_iab_dup(), and (*cap.IAB).Dup() to API. Fixed (*cap.IAB).Fill() which was previously malfunctioning for certain Inh and Amb copies. New features for capsh --quiet can be used to suppress the start up check that the local libcap is modern enough to name all of the capabilities known to the hosting kernel Added -+ and =+ arguments. These are fork+exec equivalents to -- and == respectively (that use the cap_launch API). Release notes for 2.59 libcap-2.55 ... 2.58 would SIGSEGV if an operation was attempted on a NULL value for cap_t or cap_iab_t. Restore the more tolerant error return behavior last seen with libcap-2.54. (Bug 214525) More make -j13 fixes (missing dependency for make -C progs sudotest). Various minor documentation fixes. Release notes for 2.58 Fixed a potential libcap memory leak by adding a destructor (Bug 214373 reported by yan12125) Major improvement is that there is a path for Linux-PAM compliant applications to support setting Ambient vector Capabilities via pam_cap.so now (Bug 214377) In addition to the bug, related discussion is in two Github issues: shadow-maint/shadow#408 (comment) and rra/pam-krb5#21 Added support for RPM builds that generate the build-id that RPM expects (see rpm-software-management/rpm#367 for discussion) Minor contrib/sucap/su.c cleanups Clean up kdebug build rules More documentation cleanup Release notes for 2.57 capsh enhancements: --mode makes a guess at the libcap mode of the current process (Bug 214319) --strict makes capsh less permissive and expects the user to perform more deliberate capability transactions useful for learning all the steps; and helps this article be more pedagogical. Build system fixes Preserve $(WARNINGS) (Fix from David Seifert) Don't ever build test binaries unless make test etc is invoked (speeds builds on slower systems) Support make -j12 for all, test and sudotest targets getcap -r / now generates readable output (Bug 214317) Some documentation cleanup: more consistency. Release notes for 2.56 Canonicalize the Makefile use (in collaboration with David Seifert) In the process fixed a bug in pam_cap/test_pam_cap (reported by David Seifert, Bug 214257) Doc fixes for cap_iab.3 Added color support to captree, which helped make the following fix generate readable output: Fixed captree to not display duplicate copies of sub-trees if also exploring their ancestor (Bug 214269) Fixed contrib/sucap/su to correctly handle the Inheritable flag. Release notes for 2.55 Two rounds of fixes for the results of some static analysis performed by Zoltan Fridrich Removed a clang compilation warning about memory allocation by rewriting the way cap_free() and the various libcap memory allocation mechanisms work. (Bug 214183) This generated a few broken builds until it was fixed. Cleanup of some man pages; some fixes and shorter URL to bugzilla link. Added libcap cap_proc_root() API function (to reach parity with the Go cap package). This is only potentially useful with the recently added cap_iab_get_pid() function Revamped what the GOLANG=yes builds install - used to install local copies of cap and psx, but these were effectively useless because of the Go module support in recent Go releases in favor of user controller GOPATH. Now make GOLANG=yes only installs the captree utility Added some features to captree and created a small article on it Added a man page for the captree utility Some small changes to the tests to account for the idiosyncrasies of some new testing environments I've accumulated. Included adding --has-b support to capsh Release notes for 2.54 Fix for a corner case infinite loop handling long strings (patch provided by Samanta Navarro) Fixes to not ignore allocation failures (patch provided by Samanta Navarro) Evolving work from Samanta Navarro, found and fixed a memory leak in cap_iab_get_proc() More robust discovery of the name of the dynamic loader of the build target (patch provided by Arnout Vandecappelle) Revamped the Go capability comparison API for *cap.Set and *cap.IAB: (x).Cf(), and added cap.IABGetPID() Added libcap cap_iab_compare() and cap_iab_get_pid() APIs. Added a Go utility, captree, to display the process (and thread) graph along with the POSIX.1e and IAB capabilities of each PID{TID} tree. Extended getpcaps to support the --iab command line argument, which outputs a PID's IAB tuple too (if non-default). Install *.so files as executable now that they are executable as binaries A feature of 2.52 but not extended to install rules at that time. Absorbed a lot of wisdom from a number of downstream package workarounds including wisdom from (Zhi Li and Arnout Vandecappelle and unknown others... Bugs 214023#c16, 214085) Support make FORCELINKPAM=yes or make FORCELINKPAM=no for those packagers that feel strongly about not letting this be dynamically discovered at build time. Fixed a compiler warnings from the GitHub build tester (Bug 214143) Release notes for 2.53 The (C) cap_launch functionality was previously broken when launches failed (found and fixed by Samanta Navarro) Added a test case for this too. Lots of tyops fixed in code and documentation (also by Samanta Navarro) Support distributions that aggressively link shared objects (reported by David Runge; Bug 214023) These distributions failed to observe a runnable pam_cap.so and various make options failed. Support clang builds (again). (Reported by Johan Herland 214047) This used to work, but by accident. It broke with the advent of a runnable libcap.so , libpsx.so and pam_cap.so support. Fixed now, and added a build target to validate it still works at release time. Minor documentation updates including one for Slavi Marinov who was trying to get cap.LaunchFunc() to work. Worked up a couple of example modifications to goapps/web to demonstrate a different user per web query and enabling a custom chroot per web query. Release notes for 2.52 Revived -std=c89 compilation for make all etc. (Bug 213541 reported by Byron Stanoszek.) The shared library objects: pam_cap.so, libcap.so and libpsx.so, are all now runnable as standalone binaries! The support is used to display some description information. To activate it, these binaries need to be installed executable (chmod +x ...) We also provided a write-up of how to enable this sort of feature in other .so files here. The module pam_cap.so now contains support for a default=<IAB> module argument. (Bug 213611). Enhanced capsh --suggest to also compare against the capability value names and not just their descriptions. Added capsh --current support. Minor documentation updates. Added a contrib/sucap/su.c pure-capabilities PAM implementation of su. This is primarily to demonstrate that such a thing is possible, and to validate that the pam_cap.so module is capable of adding any IAB tuple of inheritables per group or user. At this time, it relies on features only present in this version of libcap and HEAD of the Linux-PAM sources for the pam_unix.so module. Release notes for 2.51 Fix capsh installation (Bug 213261 - reported by Jan Palus) Add an autoauth module flag to pam_cap.so (Bug 213279 - noted a feature request hidden in StackExchange) Unified libcap/cap (Go) and libcap (C) default generation of external format binary data (Bug 213375 - addressing an issue raised by Mike Schilling) This standard binary format should be forwards/backwards compatible with earlier libcap2 builds and libcap/cap packages API enhancement cap_fill() and (*cap.Set).Fill() - to permit copying one capability flag to another. This can be used to raise all the Permitted capabilities in a Set with one API call. In tree build/run/test of Go packages now uses Go module vendoring (Bug 212453). This is with an eye to the imminent golang change removing support for GOPATH based building. Minor compilation warning fixes Signed-off-by: Adolf Belka <adolf.belka@ipfire.org> Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
Caveat: This is for discussion, mostly. Still need to have a policy for bounded capabilities.
Enhance login(1) and su(1) to support ambient capabilities
How things work without ambient capabilities
POSIX capabilities have been supported by Linux for quite some time now. Most distributions allow to set inheritable capabilities:
Activate
pam_cap.so
(comes with PAM enabled libcap) in your PAM config......add capabilities to users in
/etc/security/capability.conf
......and enable that capability on an executable:
Now joeuser can perform traceroutes that require raw sockets without using sudo, e.g.
While this already works on most Linux distributions, you have to set the inherited capabilities on every applicable executable, and you will have to set it again after that executable has been updated. It may be the case that joeuser is your network admin and should be allowed to use raw sockets in any application. This is where ambient capabilities come into play.
Ambient Capabilities: Granting privileges on any application
Users with ambient capabilities can use these without having them set on an executable with
setcap
. If joeuser has the ambient capability cap_net_raw, he would be able to use raw sockets in any application, even in scripting languages.Unfortunately ambient capabilities are more or less unsupported in current distributions. The main reason for this is lacking support in applications that grant access to Linux systems (like login(1) and su(1)). Those applications usually run with root privileges and drop these with the setuid() system call which clears all ambient capabilities. Generally this is a good idea, because there are many applications out there that rely on setuid() to drop all privileges.
To include support for ambient capabilities into login and su, the application has to set the "keep capabilities" flag and save the set of ambient capabilities before calling setuid(), and restore them afterwards. Since version 2.50 libcap's pam_cap.so module supports the "keepcaps" argument, which takes care of the "keep capabilities" flag. So each PAM enabled application just needs to save and restore the capabilities during setuid(). Old and new behavior can be controlled at runtime by changing the PAM configuration.
Signed-off-by: Björn Fischer bf@CeBiTec.Uni-Bielefeld.DE