On Thu, Aug 29, 2019 at 10:23 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > 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. > Not all combinations of capabilities make total sense. CAP_SETUID, for example, generally lets you get all the other capabilities. CAP_TRACE_KERNEL + CAP_TRACE_USER makes sense. CAP_TRACE_USER by itself makes sense. CAP_TRACE_READ_KERNEL_DATA without CAP_TRACE_KERNEL does not. I don't think this is a really a problem.
