How to configure the system so that users in a specific user group can execute programs requiring the cap_sys_admin capability?

Question

My primary goal is to allow users in a specific group to execute programs requiring the cap_sys_admin capability (e.g., perf) after SSH-ing into Ubuntu 22.04. A simple solution is modifying perf_event_paranoid, but this change is global and not desired. I checked the bash process spawned by sshd—getpcaps outputs =, indicating no capabilities, so perf cannot run without sudo.

I learned that sshd uses PAM for privilege management. I modified sshd_config to set UsePAM yes (uncertain if necessary for SSH key authentication) and added cap_sys_admin @mygroup before none * in /etc/security/capability.conf. After relogging, the shell process gained cap_sys_admin=i, but this capability is only in the inheritable set, preventing direct execution of perf. The capability.conf documentation confirms it affects only the inheritable set via pam_cap.so. I am now stuck on further configuration adjustments to achieve my goal.

Answer 1

You really don't want to give a regular user CAP_SYS_ADMIN. That makes them root, effectively¹. Adding the user to /etc/sudoers to allow them to run perf record (no arguments allowed) would be safer.

However, you're running Ubuntu 22.04, so your Linux distro offers you relatively modern kernels (says apt-get). That means with Kernel > 5.9, you can give a process CAP_PERFMON.

Then, next thing: Processes have capabilities that they get through invocation; users themselves don't (you can set flags on an executable file that grants capabilities based on user, though). So, you'd set the appropriate flags on the perf executable to grant it the right capabilities. The whole idea of capabilities is that you don't let a user accidentally do bad stuff, but that you use them for as shortly as possible and shed capabilities as soon as you don't need them anymore. So, starting a complete SSH session with the invoking process allowing a inherited capability sounds antithetical!

https://docs.kernel.org/admin-guide/perf-security.html details how you'd deal with this for a single executable (perf): You add a group, you make the executable's group ownership that group who becomes (aside from root) the only party able to execute the executable, and you add the user you want to execute that executable with the capability part of that group. Then, you

chmod o-wx $(type -P perf)
setcap "cap_perfmon,cap_sys_ptrace,cap_syslog=ep" $(type -P perf)

as root.

Note that most executables can just be copied and still work. You could leave the "original" perf "un-capable", and have your own, only-executable-by-the-correct-group copy of perf somewhere else. Make sure that still only root can write to that executable!

That way, you could have one perf that you use for perf record, perf stat and perf top, and one version that anyone can use for perf report.

---

¹ With CAP_SYS_ADMIN, they can mount file systems, thereby allowing themselves to run a shell (or any other program) with suid bit set, so that they get complete access as root. There's many other things you can do to become root, or you don't, because that capability allows you to do most things you could do as root, anyways.