Messages in this thread |  | | From | Jann Horn <> | Date | Wed, 3 Oct 2018 19:01:05 +0200 | Subject | Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting) |
| |
On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov <alexey.budankov@linux.intel.com> wrote: > On 01.10.2018 19:11, Thomas Gleixner wrote: > > Peter and I discussed that and we came up with the idea that the file > > descriptor is not even required, i.e. you could make it backward > > compatible. > > > > perf_event_open() knows which PMU is associated with the event the caller > > tries to open. So perf_event_open() can try to access/open the special per > > PMU file on behalf of the caller. That should get the same security > > treatment like a regular open() from user space. If that succeeds, access > > is granted. > > > > The magic file could still be writeable for root to give general > > restrictions aside of the file based ones similar to what you are > > proposing. > > Let me wrap up all the requirements and ideas that have been captured so far. > > 1. A file [1] is added so that it can belong to a group of users allowed to use ${PMU}, > something like this: > > ls -alh /sys/bus/event_source/devices/${PMU}/caps/ > total 0 > drwxr-xr-x 2 root root 0 Oct 1 20:36 . > drwxr-xr-x 6 root root 0 Oct 1 20:36 .. > -r--r--r-- 1 root root 4.0K Oct 1 20:36 branches > -r--r--r-- 1 root root 4.0K Oct 1 20:36 max_precise > -r--r--r-- 1 root root 4.0K Oct 1 20:36 pmu_name > -rw-r--r-- root ${PMU}_users paranoid <=== > > Modifications of file content are allowed to those who can > modify /proc/sys/kernel/perf_event_paranoid setting. > > 2. Semantics and content of the introduced paranoid file is > similar to /proc/sys/kernel/perf_even_paranoid [2]: > > The perf_event_paranoid file can be set to restrict access > to the performance counters. > > 2 allow only user-space measurements (default since Linux 4.6). > 1 allow both kernel and user measurements (default before Linux 4.6). > 0 allow access to CPU-specific data but not raw trace‐point samples. > -1 no restrictions. > > The existence of the perf_event_paranoid file is the official method > for determining if a kernel supports perf_event_open(). > > 3. Every time an event for ${PMU} is created over perf_event_open(): > a) the calling thread's euid is checked to belong to ${PMU}_users group > and if it does then the event's fd is allocated; > b) then traditional checks against perf_event_pranoid content are applied; > c) if the file doesn't exist the access is governed by global setting > at /proc/sys/kernel/perf_even_paranoid;
You'll also have to make sure that this thing in kernel/events/core.c doesn't have any bad effect:
/* * Special case software events and allow them to be part of * any hardware group. */
As in, make sure that you can't smuggle in arbitrary software events by attaching them to a whitelisted hardware event.
> 4. Documentation/admin-guide/perf-security.rst file is introduced that: > a) contains general explanation for fine grained access control; > b) contains a section with guidance about scope and risk for each PMU > which is enabled for fine grained access control; > c) file is extended when more PMUs are enabled for fine grain control; > > > > > The analysis and documentation requirements still remain of course. > > Security analysis for uncore IMC, QPI/UPI, PCIe PMUs is still required > to be enabled for fine grain control.
And you can't whitelist anything that permits using sampling events with arbitrary sample_type.
|  |