Messages in this thread | | | Date | Mon, 21 Aug 2023 11:07:58 -0700 | From | Kees Cook <> | Subject | Re: [RFC PATCH v1 1/1] tracing/kprobe: Add multi-probe support for 'perf_kprobe' PMU |
| |
On Mon, Aug 21, 2023 at 10:45:50AM -0400, Steven Rostedt wrote: > On Mon, 21 Aug 2023 19:01:52 +0900 > Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote: > > > > kprobe BPF program has access to pt_regs, so it can read ip of the > > > attached function. Can we do the same with regular kprobe (no bpf)? > > > > Yes, it can. So I think it is OK to expand CAP_PERFMON to access kallsyms. > > But this means CAP_PERMON itself is not safe in some case. > > What are the privileges that CAP_PERFMON gives. I can see why Kees told me > to avoid capabilities when looking at what has access to tracefs. Because > it becomes very difficult to know what the privileges you are giving when > you give out a capability. I just stick to normal ACL (file permissions) > and everything is much easier and simpler to know what has access to what.
At the very least, having a fd-based "handle" for access work. But yeah, capabilities get ugly quickly.
Anyway... what does CAP_PERFMON have access to right now? If it is allowed to read arbitrary kernel memory, then resolving symbols is fine. If it doesn't, then no, it shouldn't: it becomes a oracle for probing symbol locations.
-- Kees Cook
| |