CAP_PERFMON — and new capabilities in general

The difference, I think, is that you are describing a bug, and I am describing how the system was designed to work.

Obviously, defense in depth is a Good Thing. I am not suggesting we eliminate capabilities entirely, or that we do anything at all, for that matter. The concern is that additional complexity in privileged code (such as the kernel) carries additional risk. So when adding new layers of security, we need to balance the security benefits with the complexity. It's not clear to me how capabilities strike that balance, and under what circumstances they ought to be used in concert with or in lieu of seccomp, containerization, SELinux, etc. As a sysadmin, I would like to know which security subsystems are actually best practices, and which ones are just there because somebody wanted them to be there.

> A buggy daemon running as root will be much easier to subvert than one that runs as a normal user account with a couple of extra capabilities. Those capabilities might get you root through a few tricks, but getting the daemon to perform those steps is harder than getting it to overwrite a random file because of missing path sanitization.

This is a reasonable point. As I said, capabilities do offer some defense against confused deputies. It's just not clear to me that they are the Right Way to go about doing that.

(Of course, this is a more general problem with Linux. The man pages are great at telling you what syscall X does, but often not so good at telling you why you might want that functionality, or how you might choose to compose it with other syscalls. Section 7 pages frequently do provide this information, but they can be hard to find because it's less obvious what name you should give to man. Section 2 pages, on the other hand, tend to be rather terse. I realize this is by design, but rightly or wrongly, many people learn to program Unix by reading man pages, and this is not a great first impression.)