3

I've been inspired to start playing around with Linux capabilities again, my pet project is to replace the setuid on a lot of the binaries and provide access to additional privileged utilities to non-root users. Doing this by adding the relevant capabilities (+ei, issue is moot with +ep) via setcap and configure my personal user account (jdavis4) to have those capabilities assigned to its session at login via pam_cap.so and it's been going smashingly. I can give individual users access to "ping" and "kill" via capability.conf

The problem I'm having, though, is that it occurred to me that if this were a production system an administrator would probably want to assign capabilities by some sort of aggregate unit so that they don't have to do this for each individual user every time they make one. This way a user can just be added to the "filesystemAdmin" group and get stuff like CAP_DAC_OVERRIDE or added to "ProcessManagement" and getting stuff like CAP_SYS_NICE and CAP_SYS_KILL.

Is this currently possible?

4
  • Fedora has already done this.
    – jordanm
    May 3, 2013 at 19:22
  • Yeah, I'm seeing that there are configured capabilities on /bin/ping and what not, but my question is more about assigning capabilities by group membership than the specific part about putting capabilities on binaries. That was just backstory to explain my ultimate goal. I'm also on RHEL that doesn't have that configured yet (although if it's in Fedora, I'd suppose it's possible RHEL7 will have it).
    – Bratchley
    May 4, 2013 at 3:18
  • I'm also noticing that they're doing +ep to give everyone the capability instead of +ei that way it's sensitive to the user invoking the program.
    – Bratchley
    May 4, 2013 at 3:24
  • This article describes how to use pam to block all capabilities from being assigned to a group. blog.sevagas.com/… It has references to further discussion in the relevant portion to: friedhoff.org/posixfilecaps.html blog.sevagas.com/POSIX-file-capabilities-the-dark-side Unfortunately I'm here because I'm looking for an answer to the same question & I'm going to the park and the library for most of the rest of this weekend... ...but if you can use groups to block all capabilities, it would appear sensible to continue persu
    – 0x0065
    Jul 21, 2018 at 23:55

3 Answers 3

Reset to default
3

We added @group syntax to pam_cap.sos capability.conf support in libcap-2.29. At time of writing, libcap is at version 2.49.

There is also some documentation for pam_cap.so here.

0
+150

What you want to do is not possible. Not only does pam_cap only manipulate the inheritable capabilities (so it does not actually grant any permitted/effective capability at all), it also only deals with users and not groups (not even primary groups).

3
  • If I don't get a more complete answer I'll mark this as the answer and upvote it since it sounds about right but in order to give the bounty I need some sort of backing documentation (which I had listed as a requirement for the bounty) cause ultimately this is just some guy posting something online otherwise.
    – Bratchley
    May 6, 2013 at 20:31
  • 1
    The only documentation I have is pam_pcap.c, which I read to find an answer (I want to do something similar). It doesn't deal with groups at all, and the comments (and code) in the file also say that only inheritable capabilities are handled by it.
    – Dennis Kaarsemaker
    May 6, 2013 at 20:37
  • 1
    This statement is no longer correct. As noted in the documentation for pam_cap.so we recently added Ambient and Bounding vector support to pam_cap.so and both the Shadow suite and util-linux have just fixed their implementations to match the Linux-PAM app writers documentation to make this support useful.
    – Andrew G Morgan
    Dec 5, 2021 at 22:22
0

There is no documentation I can find to state that capability.conf can be assigned directly to a group.

This seems to be a product of the need for pam_cap to 'strip' the privileges from the authenticating process, which probably has 'all' capability, or enough to become such. This creates a propensity where it seems unwise to have cumulative additive mappings, as it could quickly become an 'uncheckable structure'. Thus assignments through capability.conf are not cumulative. If you hit a match, that is what you get. No more, no less.

With that said:

  • it is possible to configure pam_cap to load capabilities from an arbitrary file in the format of /etc/security/capability.conf

  • it is possible to use scripts within a pam config. It would be reasonably trivial to generate a per-user capability.conf file for the authenticating user, based upon their group memberships and feed it to the pam_cap module.

It's not 'elegant' or 'ideal', but for a large ldap-ish sort of user base it is probably more checkable than 'sync through layer 8 jellyware' between valid users and a full-text entry per user in a single /etc/security/capability.conf.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .