On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov
<alexey.budan...@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.
