linux-kernel - Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 2 Oct 2018 08:40:25 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Alexey Budankov <alexey.budankov@...ux.intel.com>
cc:     Jann Horn <jannh@...gle.com>, Mark Rutland <mark.rutland@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Kees Cook <keescook@...omium.org>,
        Andi Kleen <ak@...ux.intel.com>, tursulin@...ulin.net,
        kernel list <linux-kernel@...r.kernel.org>,
        tvrtko.ursulin@...ux.intel.com,
        the arch/x86 maintainers <x86@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>, acme@...nel.org,
        alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
        namhyung@...nel.org, maddy@...ux.vnet.ibm.com
Subject: Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

Alexey,

On Mon, 1 Oct 2018, Alexey Budankov wrote:
> > 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        <===

Right, though I personaly prefer something like 'access_control' as file
name, but that's bike shed painting realm.

>    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;

Not only the user group, it really should do the full security checks which
are done on open().

>    b) then traditional checks against perf_event_pranoid content are applied;

Hmm, not sure about that because that might be conflicting.

>    c) if the file doesn't exist the access is governed by global setting 
>       at /proc/sys/kernel/perf_even_paranoid;

Correct.

> 4. Documentation/admin-guide/perf-security.rst file is introduced that:

     0) Better documentation of /proc/sys/kernel/perf_even_paranoid

>    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;

Thanks,

	tglx