On Thu, Aug 29, 2019 at 08:43:23AM -0700, Andy Lutomirski wrote: > > I can imagine splitting it into three capabilities: > > CAP_TRACE_KERNEL: learn which kernel functions are called when. This > would allow perf profiling, for example, but not sampling of kernel > regs. > > CAP_TRACE_READ_KERNEL_DATA: allow the tracing, profiling, etc features > that can read the kernel's data. So you get function arguments via > kprobe, kernel regs, and APIs that expose probe_kernel_read() > > CAP_TRACE_USER: trace unrelated user processes > > I'm not sure the code is written in a way that makes splitting > CAP_TRACE_KERNEL and CAP_TRACE_READ_KERNEL_DATA, and I'm not sure that > CAP_TRACE_KERNEL is all that useful except for plain perf record > without CAP_TRACE_READ_KERNEL_DATA. What do you all think? I suppose > it could also be: > > CAP_PROFILE_KERNEL: Use perf with events that aren't kprobes or > tracepoints. Does not grant the ability to sample regs or the kernel > stack directly. > > CAP_TRACE_KERNEL: Use all of perf, ftrace, kprobe, etc. > > CAP_TRACE_USER: Use all of perf with scope limited to user mode and uprobes. imo that makes little sense from security pov, since such CAP_TRACE_KERNEL (ex kprobe) can trace "unrelated user process" just as well. Yet not letting it do cleanly via uprobe. Sort of like giving a spare key for back door of the house and saying no, you cannot have main door key.
