On Tue, 16 May 2023 17:36:28 -0700
Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote:
> "
> The user that will generate events must have x access to the tracing directory, e.g. chmod a+x /sys/kernel/tracing
> The user that will generate events must have rw access to the tracing/user_events_data file, e.g. chmod a+rw /sys/kernel/tracing/user_events_data
> "
> So any unpriv user can create and operate user events.
> Including seeing and enabling other user's user_events with 'ls/echo/cat' in tracefs.
It can see user_events_data, but x only gives you access into the directory.
It does not get you the contents of the files within the directory. The
above only gives access to the user_events_data. Which is to create events.
I recommended using groups and not giving access to all tasks.
>
> Looks like user events were designed with intention to be unprivileged.
> When I looked at kernel/trace/trace_events_user.c I assumed root.
> I doubt other people reviewed it from security perspective.
>
> Recommending "chmod a+rw /sys/kernel/tracing/user_events_data" doesn't sound like a good idea.
>
> For example, I think the following is possible:
> fd = open("/sys/kernel/tracing/user_events_data")
> ioclt(fd, DIAG_IOCSDEL)
> user_events_ioctl_del
> delete_user_event(info->group, name);
>
> 'info' is different for every FD, but info->group is the same for all users/processes/fds,
> because only one global init_group is created.
> So one user can unregister other user event by knowing 'name'.
> A security hole, no?
>
> > and libside [2] will also help here.
>
> > [2] https://github.com/compudj/libside
>
> That's an interesting project. It doesn't do any user_events access afaict,
I'll let Beau answer the rest.
-- Steve
