sysprofd unable to access perf events #614
Comments
|
@WOnder93 I'd appreciate if you could take a look at the second denial: |
|
The perf event is represented by a file descriptor, which can be passed between processes (e.g. via a UNIX socket or DBus). A perf event has a label, which is inherited from the creating process at the time of creation. My guess is that the |
|
You are correct in your description of how this works. Sysprof/Sysprof-cli use the daemon to get elevated access to perf_event FDs. |
|
What should we tell users to do on F34 to get this working? I'd like to avoid telling them to disable selinux altogether. |
|
@chergert unless somebody writes a PR earlier, I should fix it in some 2 weeks time, just as a prerequisite a new interface needs to be created. |
Perf events are represented by a file descriptor which can be passed between processes, e.g. via a UNIX socket or DBus. The perf event's label is inherited from the creating process at the time of creation. This permission is required for sysprof, executed from command line, to get elevated access to perf_event file descriptors provided by sysprofd daemon which had created the perf_event file descriptors and passed them to the client. Resolves: fedora-selinux#614
Perf events are represented by a file descriptor which can be passed between processes, e.g. via a UNIX socket or DBus. The perf event's label is inherited from the creating process at the time of creation. This permission is required for sysprof, executed from command line, to get elevated access to perf_event file descriptors provided by sysprofd daemon which had created the perf_event file descriptors and passed them to the client. The domain_read_perf_event_all_domains() interface was added. Resolves: fedora-selinux#614
Perf events are represented by a file descriptor which can be passed between processes, e.g. via a UNIX socket or DBus. The perf event's label is inherited from the creating process at the time of creation. This permission is required for sysprof, executed from command line, to get elevated access to perf_event file descriptors provided by sysprofd daemon which had created the perf_event file descriptors and passed them to the client. The domain_read_perf_event_all_domains() interface was added. Resolves: #614
|
@chergert, now there are 2 PRs to address the issue, I am sorry for the delay, should be included in the very next build. The build in the second PR (build-rpm - details - artifacts) can be used for testing, especially to find out if some other permission is needed. The lockdown permission is allowed since selinux-policy-34.4-1. |
|
Thanks! |
|
F34 Silverblue, selinux-policy-34.7-1.fc34.noarch Seems like sysprof is still unable to capture stack traces: |
|
@YaLTeR , can you install setools-console and run the following commands? I see the permissions allowed with selinux-policy-34.6-1 and newer. Can you also confirm the latest selinux-policy package version was installed before these audit records were audited? |
Yes. |
|
Is it possible the selinux-policy update failed, so it is still the old policy in place? |
Is that really possible on Silverblue? :) |
|
Still the same issue on |
@YaLTeR Can you paste the avc denials and any additional information leading to triggering your issue? |
|
I simply open Sysprof and start the capture. Then these messages appear in the journal, and upon stopping, the capture does not contain any stack traces. |
|
I did a clean F34 Silverblue install and here it works. Seems like something is broken in selinux policy updating then. |
|
Hm... coreos/fedora-coreos-tracker#701 strikes again? |
|
I did have one selinux override on my system. |
We use Sysprof all over the place in GNOME to do system profiling. I just updated to F34 today and it appears that sysprofd is now getting audit denials when trying to access perf.
The text was updated successfully, but these errors were encountered: