Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-11 Thread Joel Fernandes
On Fri, Oct 11, 2019 at 09:05:43AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 10, 2019 at 02:31:14PM -0400, Joel Fernandes wrote:
> > On Thu, Oct 10, 2019 at 07:09:49PM +0200, Peter Zijlstra wrote:
> 
> > > Yes, I did notice, I found it weird.
> > > 
> > > If you have CAP_IPC_LIMIT you should be able to bust mlock memory
> > > limits, so I don't see why we should further relate that to paranoid.
> > > 
> > > The way I wrote it, we also allow to bust the limit if we have disabled
> > > all paranoid checks. Which makes some sense I suppose.
> > > 
> > > The original commit is this:
> > > 
> > >   459ec28ab404 ("perf_counter: Allow mmap if paranoid checks are turned 
> > > off")
> > 
> > I am thinking we can just a new function perf_is_paranoid() that has nothing
> > to do with the CAP_SYS_ADMIN check and doesn't have tracepoint wording:
> > 
> > static inline int perf_is_paranoid(void)
> > {
> > return sysctl_perf_event_paranoid > -1;
> > }
> > 
> > And then call that from the mmap() code:
> > if (locked > lock_limit && perf_is_paranoid() && !capable(CAP_IPC_LOCK)) {
> > return -EPERM;
> > }
> > 
> > I don't think we need to add selinux security checks here since we are
> > already adding security checks earlier in mmap(). This will make the code 
> > and
> > its intention more clear and in line with the commit 459ec28ab404 you
> > mentioned. Thoughts?
> 
> Mostly that I'm confused by the current code ;-)
> 
> Like I said, CAP_IPC_LIMIT on its own should already allow busting the
> limit, I don't really see why we should make it conditional on paranoid.
> 
> But if you want to preserve behaviour (arguably a sane thing for your
> patch) then yes, feel free to do as you propose.

Ok, I will do it as I proposed above and resend patch today. Thanks!

 - Joel



Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-11 Thread Peter Zijlstra
On Thu, Oct 10, 2019 at 02:31:14PM -0400, Joel Fernandes wrote:
> On Thu, Oct 10, 2019 at 07:09:49PM +0200, Peter Zijlstra wrote:

> > Yes, I did notice, I found it weird.
> > 
> > If you have CAP_IPC_LIMIT you should be able to bust mlock memory
> > limits, so I don't see why we should further relate that to paranoid.
> > 
> > The way I wrote it, we also allow to bust the limit if we have disabled
> > all paranoid checks. Which makes some sense I suppose.
> > 
> > The original commit is this:
> > 
> >   459ec28ab404 ("perf_counter: Allow mmap if paranoid checks are turned 
> > off")
> 
> I am thinking we can just a new function perf_is_paranoid() that has nothing
> to do with the CAP_SYS_ADMIN check and doesn't have tracepoint wording:
> 
> static inline int perf_is_paranoid(void)
> {
>   return sysctl_perf_event_paranoid > -1;
> }
> 
> And then call that from the mmap() code:
> if (locked > lock_limit && perf_is_paranoid() && !capable(CAP_IPC_LOCK)) {
>   return -EPERM;
> }
> 
> I don't think we need to add selinux security checks here since we are
> already adding security checks earlier in mmap(). This will make the code and
> its intention more clear and in line with the commit 459ec28ab404 you
> mentioned. Thoughts?

Mostly that I'm confused by the current code ;-)

Like I said, CAP_IPC_LIMIT on its own should already allow busting the
limit, I don't really see why we should make it conditional on paranoid.

But if you want to preserve behaviour (arguably a sane thing for your
patch) then yes, feel free to do as you propose.


Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-10 Thread James Morris
On Thu, 10 Oct 2019, Casey Schaufler wrote:

> > Because it is not necessary.
> 
> The logic escapes me, but OK.

We should only extend the stacking infrastructure to what is concretely 
required. We don't yet have a use-case for stacking perf_event so we 
should keep the code as simple as possible. As soon as multiple LSMs 
determine they need to share the blob, we can convert the code to blob 
sharing.


-- 
James Morris




Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-10 Thread Joel Fernandes
On Thu, Oct 10, 2019 at 07:09:49PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 10, 2019 at 11:13:33AM -0400, Joel Fernandes wrote:
> > On Thu, Oct 10, 2019 at 10:12:51AM +0200, Peter Zijlstra wrote:
> > > +static inline int perf_allow_tracepoint(struct perf_event_attr *attr)
> > >  {
> > > - return sysctl_perf_event_paranoid > 1;
> > > + if (sysctl_perf_event_paranoid > -1 && !capable(CAP_SYS_ADMIN))
> > > + return -EPERM;
> > > +
> > 
> > Here the sysctl check of > -1 also is now coupled with a CAP_SYS_ADMIN 
> > check.
> > However..
> > 
> > > + return security_perf_event_open(attr, PERF_SECURITY_TRACEPOINT);
> > 
> > >  }
> > >  
> > > --- a/kernel/events/core.c
> > > +++ b/kernel/events/core.c
> 
> > > @@ -5862,14 +5859,8 @@ static int perf_mmap(struct file *file,
> > >   lock_limit >>= PAGE_SHIFT;
> > >   locked = atomic64_read(>vm_mm->pinned_vm) + extra;
> > >  
> > > - if (locked > lock_limit) {
> > > - if (perf_paranoid_tracepoint_raw() && !capable(CAP_IPC_LOCK)) {
> > > - ret = -EPERM;
> > > - goto unlock;
> > > - }
> > > -
> > > - ret = security_perf_event_open(>attr,
> > > -PERF_SECURITY_TRACEPOINT);
> > > + if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
> > > + ret = perf_allow_tracepoint(>attr);
> > 
> > In previous code, this check did not involve a check for CAP_SYS_ADMIN.
> > 
> > I am Ok with adding the CAP_SYS_ADMIN check as well which does make sense to
> > me for tracepoint access. But it is still a change in the logic so I wanted
> > to bring it up.
> > 
> > Let me know any other thoughts and then I'll post a new patch.
> 
> Yes, I did notice, I found it weird.
> 
> If you have CAP_IPC_LIMIT you should be able to bust mlock memory
> limits, so I don't see why we should further relate that to paranoid.
> 
> The way I wrote it, we also allow to bust the limit if we have disabled
> all paranoid checks. Which makes some sense I suppose.
> 
> The original commit is this:
> 
>   459ec28ab404 ("perf_counter: Allow mmap if paranoid checks are turned off")

I am thinking we can just a new function perf_is_paranoid() that has nothing
to do with the CAP_SYS_ADMIN check and doesn't have tracepoint wording:

static inline int perf_is_paranoid(void)
{
return sysctl_perf_event_paranoid > -1;
}

And then call that from the mmap() code:
if (locked > lock_limit && perf_is_paranoid() && !capable(CAP_IPC_LOCK)) {
return -EPERM;
}

I don't think we need to add selinux security checks here since we are
already adding security checks earlier in mmap(). This will make the code and
its intention more clear and in line with the commit 459ec28ab404 you
mentioned. Thoughts?

thanks,

 - Joel



Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-10 Thread Casey Schaufler
On 10/9/2019 7:44 PM, James Morris wrote:
> On Wed, 9 Oct 2019, Casey Schaufler wrote:
>
>> On 10/9/2019 3:14 PM, James Morris wrote:
>>> On Wed, 9 Oct 2019, Casey Schaufler wrote:
>>>
 Please consider making the perf_alloc security blob maintained
 by the infrastructure rather than the individual modules. This
 will save it having to be changed later.
>>> Is anyone planning on using this with full stacking?
>>>
>>> If not, we don't need the extra code & complexity. Stacking should only 
>>> cover what's concretely required by in-tree users.
>> I don't believe it's any simpler for SELinux to do the allocation
>> than for the infrastructure to do it. I don't see anyone's head
>> exploding over the existing infrastructure allocation of blobs.
>> We're likely to want it at some point, so why not avoid the hassle
>> and delay by doing it the "new" way up front?
> Because it is not necessary.

The logic escapes me, but OK.



Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-10 Thread Peter Zijlstra
On Thu, Oct 10, 2019 at 11:13:33AM -0400, Joel Fernandes wrote:
> On Thu, Oct 10, 2019 at 10:12:51AM +0200, Peter Zijlstra wrote:
> > +static inline int perf_allow_tracepoint(struct perf_event_attr *attr)
> >  {
> > -   return sysctl_perf_event_paranoid > 1;
> > +   if (sysctl_perf_event_paranoid > -1 && !capable(CAP_SYS_ADMIN))
> > +   return -EPERM;
> > +
> 
> Here the sysctl check of > -1 also is now coupled with a CAP_SYS_ADMIN check.
> However..
> 
> > +   return security_perf_event_open(attr, PERF_SECURITY_TRACEPOINT);
> 
> >  }
> >  
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c

> > @@ -5862,14 +5859,8 @@ static int perf_mmap(struct file *file,
> > lock_limit >>= PAGE_SHIFT;
> > locked = atomic64_read(>vm_mm->pinned_vm) + extra;
> >  
> > -   if (locked > lock_limit) {
> > -   if (perf_paranoid_tracepoint_raw() && !capable(CAP_IPC_LOCK)) {
> > -   ret = -EPERM;
> > -   goto unlock;
> > -   }
> > -
> > -   ret = security_perf_event_open(>attr,
> > -  PERF_SECURITY_TRACEPOINT);
> > +   if (locked > lock_limit && !capable(CAP_IPC_LOCK)) {
> > +   ret = perf_allow_tracepoint(>attr);
> 
> In previous code, this check did not involve a check for CAP_SYS_ADMIN.
> 
> I am Ok with adding the CAP_SYS_ADMIN check as well which does make sense to
> me for tracepoint access. But it is still a change in the logic so I wanted
> to bring it up.
> 
> Let me know any other thoughts and then I'll post a new patch.

Yes, I did notice, I found it weird.

If you have CAP_IPC_LIMIT you should be able to bust mlock memory
limits, so I don't see why we should further relate that to paranoid.

The way I wrote it, we also allow to bust the limit if we have disabled
all paranoid checks. Which makes some sense I suppose.

The original commit is this:

  459ec28ab404 ("perf_counter: Allow mmap if paranoid checks are turned off")


Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-10 Thread Joel Fernandes
On Thu, Oct 10, 2019 at 10:12:51AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 09, 2019 at 04:36:57PM -0400, Joel Fernandes (Google) wrote:
> > In currentl mainline, the degree of access to perf_event_open(2) system
> > call depends on the perf_event_paranoid sysctl.  This has a number of
> > limitations:
> > 
> > 1. The sysctl is only a single value. Many types of accesses are controlled
> >based on the single value thus making the control very limited and
> >coarse grained.
> > 2. The sysctl is global, so if the sysctl is changed, then that means
> >all processes get access to perf_event_open(2) opening the door to
> >security issues.
> > 
> > This patch adds LSM and SELinux access checking which will be used in
> > Android to access perf_event_open(2) for the purposes of attaching BPF
> > programs to tracepoints, perf profiling and other operations from
> > userspace. These operations are intended for production systems.
> > 
> > 5 new LSM hooks are added:
> > 1. perf_event_open: This controls access during the perf_event_open(2)
> >syscall itself. The hook is called from all the places that the
> >perf_event_paranoid sysctl is checked to keep it consistent with the
> >systctl. The hook gets passed a 'type' argument which controls CPU,
> >kernel and tracepoint accesses (in this context, CPU, kernel and
> >tracepoint have the same semantics as the perf_event_paranoid sysctl).
> >Additionally, I added an 'open' type which is similar to
> >perf_event_paranoid sysctl == 3 patch carried in Android and several 
> > other
> >distros but was rejected in mainline [1] in 2016.
> > 
> > 2. perf_event_alloc: This allocates a new security object for the event
> >which stores the current SID within the event. It will be useful when
> >the perf event's FD is passed through IPC to another process which may
> >try to read the FD. Appropriate security checks will limit access.
> > 
> > 3. perf_event_free: Called when the event is closed.
> > 
> > 4. perf_event_read: Called from the read(2) system call path for the event.
> 
>   + mmap()
> > 
> > 5. perf_event_write: Called from the read(2) system call path for the event.
> 
>   - read() + ioctl()

Fixed.

> 
> fresh from the keyboard.. but maybe consoldate things a little.

Looks great to me, I folded it into the patch. Thanks Peter! Just one comment
on change in existing logic of the code, below:

[snip]
> --- a/arch/x86/events/intel/p4.c
> +++ b/arch/x86/events/intel/p4.c
> @@ -8,7 +8,6 @@
>   */
>  
>  #include 
> -#include 
>  
>  #include 
>  #include 
> @@ -777,10 +776,7 @@ static int p4_validate_raw_event(struct
>* the user needs special permissions to be able to use it
>*/
>   if (p4_ht_active() && p4_event_bind_map[v].shared) {
> - if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
> - return -EACCES;
> -
> - v = security_perf_event_open(>attr, PERF_SECURITY_CPU);
> + v = perf_allow_cpu(>attr);
>   if (v)
>   return v;
>   }
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -56,6 +56,7 @@ struct perf_guest_info_callbacks {
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct perf_callchain_entry {
> @@ -1244,19 +1245,28 @@ extern int perf_cpu_time_max_percent_han
>  int perf_event_max_stack_handler(struct ctl_table *table, int write,
>void __user *buffer, size_t *lenp, loff_t 
> *ppos);
>  
> -static inline bool perf_paranoid_tracepoint_raw(void)
> +static inline int perf_allow_kernel(struct perf_event_attr *attr)
>  {
> - return sysctl_perf_event_paranoid > -1;
> + if (sysctl_perf_event_paranoid > 1 && !capable(CAP_SYS_ADMIN))
> + return -EACCES;
> +
> + return security_perf_event_open(attr, PERF_SECURITY_KERNEL);
>  }
>  
> -static inline bool perf_paranoid_cpu(void)
> +static inline int perf_allow_cpu(struct perf_event_attr *attr)
>  {
> - return sysctl_perf_event_paranoid > 0;
> + if (sysctl_perf_event_paranoid > 0 && !capable(CAP_SYS_ADMIN))
> + return -EACCES;
> +
> + return security_perf_event_open(attr, PERF_SECURITY_CPU);
>  }
>  
> -static inline bool perf_paranoid_kernel(void)
> +static inline int perf_allow_tracepoint(struct perf_event_attr *attr)
>  {
> - return sysctl_perf_event_paranoid > 1;
> + if (sysctl_perf_event_paranoid > -1 && !capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +

Here the sysctl check of > -1 also is now coupled with a CAP_SYS_ADMIN check.
However..

> + return security_perf_event_open(attr, PERF_SECURITY_TRACEPOINT);

>  }
>  
>  extern void perf_event_init(void);
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4229,10 +4229,7 @@ find_get_context(struct pmu *pmu, struct
>  
>   if (!task) {
>   /* Must be root to operate on a CPU event: */
> - if 

Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-10 Thread Peter Zijlstra
On Wed, Oct 09, 2019 at 04:36:57PM -0400, Joel Fernandes (Google) wrote:
> In currentl mainline, the degree of access to perf_event_open(2) system
> call depends on the perf_event_paranoid sysctl.  This has a number of
> limitations:
> 
> 1. The sysctl is only a single value. Many types of accesses are controlled
>based on the single value thus making the control very limited and
>coarse grained.
> 2. The sysctl is global, so if the sysctl is changed, then that means
>all processes get access to perf_event_open(2) opening the door to
>security issues.
> 
> This patch adds LSM and SELinux access checking which will be used in
> Android to access perf_event_open(2) for the purposes of attaching BPF
> programs to tracepoints, perf profiling and other operations from
> userspace. These operations are intended for production systems.
> 
> 5 new LSM hooks are added:
> 1. perf_event_open: This controls access during the perf_event_open(2)
>syscall itself. The hook is called from all the places that the
>perf_event_paranoid sysctl is checked to keep it consistent with the
>systctl. The hook gets passed a 'type' argument which controls CPU,
>kernel and tracepoint accesses (in this context, CPU, kernel and
>tracepoint have the same semantics as the perf_event_paranoid sysctl).
>Additionally, I added an 'open' type which is similar to
>perf_event_paranoid sysctl == 3 patch carried in Android and several other
>distros but was rejected in mainline [1] in 2016.
> 
> 2. perf_event_alloc: This allocates a new security object for the event
>which stores the current SID within the event. It will be useful when
>the perf event's FD is passed through IPC to another process which may
>try to read the FD. Appropriate security checks will limit access.
> 
> 3. perf_event_free: Called when the event is closed.
> 
> 4. perf_event_read: Called from the read(2) system call path for the event.

+ mmap()
> 
> 5. perf_event_write: Called from the read(2) system call path for the event.

- read() + ioctl()

fresh from the keyboard.. but maybe consoldate things a little.

---
--- a/arch/x86/events/intel/bts.c
+++ b/arch/x86/events/intel/bts.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -550,13 +549,11 @@ static int bts_event_init(struct perf_ev
 * Note that the default paranoia setting permits unprivileged
 * users to profile the kernel.
 */
-   if (event->attr.exclude_kernel && perf_paranoid_kernel() &&
-   !capable(CAP_SYS_ADMIN))
-   return -EACCES;
-
-   ret = security_perf_event_open(>attr, PERF_SECURITY_KERNEL);
-   if (ret)
-   return ret;
+   if (event->attr.exclude_kernel) {
+   ret = perf_allow_kernel(>attr);
+   if (ret)
+   return ret;
+   }
 
if (x86_add_exclusive(x86_lbr_exclusive_bts))
return -EBUSY;
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -3316,10 +3315,7 @@ static int intel_pmu_hw_config(struct pe
if (x86_pmu.version < 3)
return -EINVAL;
 
-   if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
-   return -EACCES;
-
-   ret = security_perf_event_open(>attr, PERF_SECURITY_CPU);
+   ret = perf_allow_cpu(>attr);
if (ret)
return ret;
 
--- a/arch/x86/events/intel/p4.c
+++ b/arch/x86/events/intel/p4.c
@@ -8,7 +8,6 @@
  */
 
 #include 
-#include 
 
 #include 
 #include 
@@ -777,10 +776,7 @@ static int p4_validate_raw_event(struct
 * the user needs special permissions to be able to use it
 */
if (p4_ht_active() && p4_event_bind_map[v].shared) {
-   if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
-   return -EACCES;
-
-   v = security_perf_event_open(>attr, PERF_SECURITY_CPU);
+   v = perf_allow_cpu(>attr);
if (v)
return v;
}
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -56,6 +56,7 @@ struct perf_guest_info_callbacks {
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct perf_callchain_entry {
@@ -1244,19 +1245,28 @@ extern int perf_cpu_time_max_percent_han
 int perf_event_max_stack_handler(struct ctl_table *table, int write,
 void __user *buffer, size_t *lenp, loff_t 
*ppos);
 
-static inline bool perf_paranoid_tracepoint_raw(void)
+static inline int perf_allow_kernel(struct perf_event_attr *attr)
 {
-   return sysctl_perf_event_paranoid > -1;
+   if (sysctl_perf_event_paranoid > 1 && !capable(CAP_SYS_ADMIN))
+   return -EACCES;
+
+   return security_perf_event_open(attr, PERF_SECURITY_KERNEL);
 }
 
-static inline bool perf_paranoid_cpu(void)
+static 

Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-10 Thread Alexey Budankov
Hi Joel,

Thanks for the patch.

On 09.10.2019 23:36, Joel Fernandes (Google) wrote:
> In currentl mainline, the degree of access to perf_event_open(2) system
> call depends on the perf_event_paranoid sysctl.  This has a number of
> limitations:
> 
> 1. The sysctl is only a single value. Many types of accesses are controlled
>based on the single value thus making the control very limited and
>coarse grained.
> 2. The sysctl is global, so if the sysctl is changed, then that means
>all processes get access to perf_event_open(2) opening the door to
>security issues.

Please also see considerations here: Documentation/admin-guide/perf-security.rst
According to the document Perf based monitoring can be configured for usage 
by Perf user groups. This option extends perf_event access control beyond 
perf_event_paranoid kernel setting.

One of the possible future steps from that could be to move perf_events
monitoring from under overloaded CAP_SYS_ADMIN to a dedicated CAP_SYS_PERFMON.

It would be appreciated if Perf user groups approach continue be applicable 
as currently documented. Existing Perf tool implementation already relies on it.

It would be also beneficial to augment the document with related information 
regarding Perf extensions related to kernel security.

Thanks,
Alexey

> 
> This patch adds LSM and SELinux access checking which will be used in
> Android to access perf_event_open(2) for the purposes of attaching BPF
> programs to tracepoints, perf profiling and other operations from
> userspace. These operations are intended for production systems.
> 
> 5 new LSM hooks are added:
> 1. perf_event_open: This controls access during the perf_event_open(2)
>syscall itself. The hook is called from all the places that the
>perf_event_paranoid sysctl is checked to keep it consistent with the
>systctl. The hook gets passed a 'type' argument which controls CPU,
>kernel and tracepoint accesses (in this context, CPU, kernel and
>tracepoint have the same semantics as the perf_event_paranoid sysctl).
>Additionally, I added an 'open' type which is similar to
>perf_event_paranoid sysctl == 3 patch carried in Android and several other
>distros but was rejected in mainline [1] in 2016.
> 
> 2. perf_event_alloc: This allocates a new security object for the event
>which stores the current SID within the event. It will be useful when
>the perf event's FD is passed through IPC to another process which may
>try to read the FD. Appropriate security checks will limit access.
> 
> 3. perf_event_free: Called when the event is closed.
> 
> 4. perf_event_read: Called from the read(2) system call path for the event.
> 
> 5. perf_event_write: Called from the read(2) system call path for the event.
> 
> [1] https://lwn.net/Articles/696240/
> 
> Since Peter had suggest LSM hooks in 2016 [1], I am adding his
> Suggested-by tag below.
> 
> To use this patch, we set the perf_event_paranoid sysctl to -1 and then
> apply selinux checking as appropriate (default deny everything, and then
> add policy rules to give access to domains that need it). In the future
> we can remove the perf_event_paranoid sysctl altogether.
> 
> Suggested-by: Peter Zijlstra 
> Cc: Peter Zijlstra 
> Cc: rost...@goodmis.org
> Cc: primi...@google.com
> Cc: rsavit...@google.com
> Cc: je...@google.com
> Cc: kernel-t...@android.com
> Signed-off-by: Joel Fernandes (Google) 
> 
> ---
>  arch/x86/events/intel/bts.c |  5 +++
>  arch/x86/events/intel/core.c|  5 +++
>  arch/x86/events/intel/p4.c  |  5 +++
>  include/linux/lsm_hooks.h   | 15 +++
>  include/linux/perf_event.h  |  3 ++
>  include/linux/security.h| 39 +++-
>  include/uapi/linux/perf_event.h | 13 ++
>  kernel/events/core.c| 59 +---
>  kernel/trace/trace_event_perf.c | 15 ++-
>  security/security.c | 33 ++
>  security/selinux/hooks.c| 69 +
>  security/selinux/include/classmap.h |  2 +
>  security/selinux/include/objsec.h   |  6 ++-
>  13 files changed, 259 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c
> index 5ee3fed881d3..9796fc094dad 100644
> --- a/arch/x86/events/intel/bts.c
> +++ b/arch/x86/events/intel/bts.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -553,6 +554,10 @@ static int bts_event_init(struct perf_event *event)
>   !capable(CAP_SYS_ADMIN))
>   return -EACCES;
>  
> + ret = security_perf_event_open(>attr, PERF_SECURITY_KERNEL);
> + if (ret)
> + return ret;
> +
>   if (x86_add_exclusive(x86_lbr_exclusive_bts))
>   return -EBUSY;
>  
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 27ee47a7be66..75b6b9b239ae 100644
> --- 

Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-09 Thread James Morris
On Wed, 9 Oct 2019, Casey Schaufler wrote:

> On 10/9/2019 3:14 PM, James Morris wrote:
> > On Wed, 9 Oct 2019, Casey Schaufler wrote:
> >
> >> Please consider making the perf_alloc security blob maintained
> >> by the infrastructure rather than the individual modules. This
> >> will save it having to be changed later.
> > Is anyone planning on using this with full stacking?
> >
> > If not, we don't need the extra code & complexity. Stacking should only 
> > cover what's concretely required by in-tree users.
> 
> I don't believe it's any simpler for SELinux to do the allocation
> than for the infrastructure to do it. I don't see anyone's head
> exploding over the existing infrastructure allocation of blobs.
> We're likely to want it at some point, so why not avoid the hassle
> and delay by doing it the "new" way up front?

Because it is not necessary.

-- 
James Morris




Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-09 Thread Casey Schaufler
On 10/9/2019 5:40 PM, Joel Fernandes wrote:
> On Wed, Oct 09, 2019 at 03:41:56PM -0700, Casey Schaufler wrote:
>> On 10/9/2019 3:14 PM, James Morris wrote:
>>> On Wed, 9 Oct 2019, Casey Schaufler wrote:
>>>
 Please consider making the perf_alloc security blob maintained
 by the infrastructure rather than the individual modules. This
 will save it having to be changed later.
>>> Is anyone planning on using this with full stacking?
>>>
>>> If not, we don't need the extra code & complexity. Stacking should only 
>>> cover what's concretely required by in-tree users.
>> I don't believe it's any simpler for SELinux to do the allocation
>> than for the infrastructure to do it. I don't see anyone's head
>> exploding over the existing infrastructure allocation of blobs.
>> We're likely to want it at some point, so why not avoid the hassle
>> and delay by doing it the "new" way up front?
>>
> I don't see how it can be maintained by the users (assuming you meant
> infrastructure as perf_event subsystem).

No, I meant allocated in security.c. Look at how file blobs are allocated.

>  The blob contains a SID which as far
> as I know, is specific to SELinux. Do you have an in-tree example of this?
>
> Further, this is also exactly it is done for BPF objects which I used as a
> reference.

There's no real harm in doing it that way, just that it is a change that
I'll have to make at some point in the future* and it would be really nice
if I didn't have to.

> thanks,
>
>  - Joel

-
* When? After I get the current AppArmor/SELinux stacking enabling in
  and can get to the Smack backlong, which includes BPF and perf_events.
 




Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-09 Thread Joel Fernandes
On Thu, Oct 10, 2019 at 09:11:39AM +1100, James Morris wrote:
> On Wed, 9 Oct 2019, Joel Fernandes (Google) wrote:
> 
> >  
> > +#ifdef CONFIG_SECURITY
> > +   err = security_perf_event_alloc(event);
> > +   if (err)
> > +   goto err_security;
> > +#endif
> 
> You should not need this ifdef.

Fixed.

> > diff --git a/security/security.c b/security/security.c
> > index 1bc000f834e2..7639bca1db59 100644
> > --- a/security/security.c
> > +++ b/security/security.c
> > @@ -2373,26 +2373,32 @@ int security_bpf(int cmd, union bpf_attr *attr, 
> > unsigned int size)
> >  {
> > return call_int_hook(bpf, 0, cmd, attr, size);
> >  }
> > +
> >  int security_bpf_map(struct bpf_map *map, fmode_t fmode)
> >  {
> > return call_int_hook(bpf_map, 0, map, fmode);
> >  }
> > +
> >  int security_bpf_prog(struct bpf_prog *prog)
> >  {
> > return call_int_hook(bpf_prog, 0, prog);
> >  }
> > +
> >  int security_bpf_map_alloc(struct bpf_map *map)
> >  {
> > return call_int_hook(bpf_map_alloc_security, 0, map);
> >  }
> > +
> >  int security_bpf_prog_alloc(struct bpf_prog_aux *aux)
> >  {
> > return call_int_hook(bpf_prog_alloc_security, 0, aux);
> >  }
> > +
> >  void security_bpf_map_free(struct bpf_map *map)
> >  {
> > call_void_hook(bpf_map_free_security, map);
> >  }
> > +
> >  void security_bpf_prog_free(struct bpf_prog_aux *aux)
> >  {
> > call_void_hook(bpf_prog_free_security, aux);
> > @@ -2404,3 +2410,30 @@ int security_locked_down(enum lockdown_reason what)
> > return call_int_hook(locked_down, 0, what);
> >  }
> >  EXPORT_SYMBOL(security_locked_down);
> 
> Please avoid unrelated whitespace changes.

The author of the BPF security hooks forgot to add a newline between function
definitions and I was just cleaning the style issue since it is very close to
the parts I touched. But I will drop it from the patch per your suggestion.

thanks,

 - Joel



Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-09 Thread Joel Fernandes
On Wed, Oct 09, 2019 at 03:41:56PM -0700, Casey Schaufler wrote:
> On 10/9/2019 3:14 PM, James Morris wrote:
> > On Wed, 9 Oct 2019, Casey Schaufler wrote:
> >
> >> Please consider making the perf_alloc security blob maintained
> >> by the infrastructure rather than the individual modules. This
> >> will save it having to be changed later.
> > Is anyone planning on using this with full stacking?
> >
> > If not, we don't need the extra code & complexity. Stacking should only 
> > cover what's concretely required by in-tree users.
> 
> I don't believe it's any simpler for SELinux to do the allocation
> than for the infrastructure to do it. I don't see anyone's head
> exploding over the existing infrastructure allocation of blobs.
> We're likely to want it at some point, so why not avoid the hassle
> and delay by doing it the "new" way up front?
> 

I don't see how it can be maintained by the users (assuming you meant
infrastructure as perf_event subsystem). The blob contains a SID which as far
as I know, is specific to SELinux. Do you have an in-tree example of this?

Further, this is also exactly it is done for BPF objects which I used as a
reference.

thanks,

 - Joel



Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-09 Thread Casey Schaufler
On 10/9/2019 3:14 PM, James Morris wrote:
> On Wed, 9 Oct 2019, Casey Schaufler wrote:
>
>> Please consider making the perf_alloc security blob maintained
>> by the infrastructure rather than the individual modules. This
>> will save it having to be changed later.
> Is anyone planning on using this with full stacking?
>
> If not, we don't need the extra code & complexity. Stacking should only 
> cover what's concretely required by in-tree users.

I don't believe it's any simpler for SELinux to do the allocation
than for the infrastructure to do it. I don't see anyone's head
exploding over the existing infrastructure allocation of blobs.
We're likely to want it at some point, so why not avoid the hassle
and delay by doing it the "new" way up front?




Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-09 Thread James Morris
On Wed, 9 Oct 2019, Casey Schaufler wrote:

> Please consider making the perf_alloc security blob maintained
> by the infrastructure rather than the individual modules. This
> will save it having to be changed later.

Is anyone planning on using this with full stacking?

If not, we don't need the extra code & complexity. Stacking should only 
cover what's concretely required by in-tree users.

-- 
James Morris




Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-09 Thread James Morris
On Wed, 9 Oct 2019, Joel Fernandes (Google) wrote:

>  
> +#ifdef CONFIG_SECURITY
> + err = security_perf_event_alloc(event);
> + if (err)
> + goto err_security;
> +#endif

You should not need this ifdef.

> diff --git a/security/security.c b/security/security.c
> index 1bc000f834e2..7639bca1db59 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -2373,26 +2373,32 @@ int security_bpf(int cmd, union bpf_attr *attr, 
> unsigned int size)
>  {
>   return call_int_hook(bpf, 0, cmd, attr, size);
>  }
> +
>  int security_bpf_map(struct bpf_map *map, fmode_t fmode)
>  {
>   return call_int_hook(bpf_map, 0, map, fmode);
>  }
> +
>  int security_bpf_prog(struct bpf_prog *prog)
>  {
>   return call_int_hook(bpf_prog, 0, prog);
>  }
> +
>  int security_bpf_map_alloc(struct bpf_map *map)
>  {
>   return call_int_hook(bpf_map_alloc_security, 0, map);
>  }
> +
>  int security_bpf_prog_alloc(struct bpf_prog_aux *aux)
>  {
>   return call_int_hook(bpf_prog_alloc_security, 0, aux);
>  }
> +
>  void security_bpf_map_free(struct bpf_map *map)
>  {
>   call_void_hook(bpf_map_free_security, map);
>  }
> +
>  void security_bpf_prog_free(struct bpf_prog_aux *aux)
>  {
>   call_void_hook(bpf_prog_free_security, aux);
> @@ -2404,3 +2410,30 @@ int security_locked_down(enum lockdown_reason what)
>   return call_int_hook(locked_down, 0, what);
>  }
>  EXPORT_SYMBOL(security_locked_down);

Please avoid unrelated whitespace changes.


-- 
James Morris




Re: [PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-09 Thread Casey Schaufler
On 10/9/2019 1:36 PM, Joel Fernandes (Google) wrote:
> In currentl mainline, the degree of access to perf_event_open(2) system
> call depends on the perf_event_paranoid sysctl.  This has a number of
> limitations:
>
> 1. The sysctl is only a single value. Many types of accesses are controlled
>based on the single value thus making the control very limited and
>coarse grained.
> 2. The sysctl is global, so if the sysctl is changed, then that means
>all processes get access to perf_event_open(2) opening the door to
>security issues.
>
> This patch adds LSM and SELinux access checking which will be used in
> Android to access perf_event_open(2) for the purposes of attaching BPF
> programs to tracepoints, perf profiling and other operations from
> userspace. These operations are intended for production systems.
>
> 5 new LSM hooks are added:
> 1. perf_event_open: This controls access during the perf_event_open(2)
>syscall itself. The hook is called from all the places that the
>perf_event_paranoid sysctl is checked to keep it consistent with the
>systctl. The hook gets passed a 'type' argument which controls CPU,
>kernel and tracepoint accesses (in this context, CPU, kernel and
>tracepoint have the same semantics as the perf_event_paranoid sysctl).
>Additionally, I added an 'open' type which is similar to
>perf_event_paranoid sysctl == 3 patch carried in Android and several other
>distros but was rejected in mainline [1] in 2016.
>
> 2. perf_event_alloc: This allocates a new security object for the event
>which stores the current SID within the event. It will be useful when
>the perf event's FD is passed through IPC to another process which may
>try to read the FD. Appropriate security checks will limit access.

s/which stores the current SID within the event//

While it may be true for SELinux, the data stored is up to the
security modules and may not include a SID.

Please consider making the perf_alloc security blob maintained
by the infrastructure rather than the individual modules. This
will save it having to be changed later.

> 3. perf_event_free: Called when the event is closed.
>
> 4. perf_event_read: Called from the read(2) system call path for the event.
>
> 5. perf_event_write: Called from the read(2) system call path for the event.
>
> [1] https://lwn.net/Articles/696240/
>
> Since Peter had suggest LSM hooks in 2016 [1], I am adding his
> Suggested-by tag below.
>
> To use this patch, we set the perf_event_paranoid sysctl to -1 and then
> apply selinux checking as appropriate (default deny everything, and then
> add policy rules to give access to domains that need it). In the future
> we can remove the perf_event_paranoid sysctl altogether.
>
> Suggested-by: Peter Zijlstra 
> Cc: Peter Zijlstra 
> Cc: rost...@goodmis.org
> Cc: primi...@google.com
> Cc: rsavit...@google.com
> Cc: je...@google.com
> Cc: kernel-t...@android.com
> Signed-off-by: Joel Fernandes (Google) 
>
> ---
>  arch/x86/events/intel/bts.c |  5 +++
>  arch/x86/events/intel/core.c|  5 +++
>  arch/x86/events/intel/p4.c  |  5 +++
>  include/linux/lsm_hooks.h   | 15 +++
>  include/linux/perf_event.h  |  3 ++
>  include/linux/security.h| 39 +++-
>  include/uapi/linux/perf_event.h | 13 ++
>  kernel/events/core.c| 59 +---
>  kernel/trace/trace_event_perf.c | 15 ++-
>  security/security.c | 33 ++
>  security/selinux/hooks.c| 69 +
>  security/selinux/include/classmap.h |  2 +
>  security/selinux/include/objsec.h   |  6 ++-
>  13 files changed, 259 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c
> index 5ee3fed881d3..9796fc094dad 100644
> --- a/arch/x86/events/intel/bts.c
> +++ b/arch/x86/events/intel/bts.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -553,6 +554,10 @@ static int bts_event_init(struct perf_event *event)
>   !capable(CAP_SYS_ADMIN))
>   return -EACCES;
>  
> + ret = security_perf_event_open(>attr, PERF_SECURITY_KERNEL);
> + if (ret)
> + return ret;
> +
>   if (x86_add_exclusive(x86_lbr_exclusive_bts))
>   return -EBUSY;
>  
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 27ee47a7be66..75b6b9b239ae 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3318,6 +3319,10 @@ static int intel_pmu_hw_config(struct perf_event 
> *event)
>   if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
>   return -EACCES;
>  
> + ret = security_perf_event_open(>attr, PERF_SECURITY_CPU);
> + if (ret)
> + return ret;
> 

[PATCH RFC] perf_event: Add support for LSM and SELinux checks

2019-10-09 Thread Joel Fernandes (Google)
In currentl mainline, the degree of access to perf_event_open(2) system
call depends on the perf_event_paranoid sysctl.  This has a number of
limitations:

1. The sysctl is only a single value. Many types of accesses are controlled
   based on the single value thus making the control very limited and
   coarse grained.
2. The sysctl is global, so if the sysctl is changed, then that means
   all processes get access to perf_event_open(2) opening the door to
   security issues.

This patch adds LSM and SELinux access checking which will be used in
Android to access perf_event_open(2) for the purposes of attaching BPF
programs to tracepoints, perf profiling and other operations from
userspace. These operations are intended for production systems.

5 new LSM hooks are added:
1. perf_event_open: This controls access during the perf_event_open(2)
   syscall itself. The hook is called from all the places that the
   perf_event_paranoid sysctl is checked to keep it consistent with the
   systctl. The hook gets passed a 'type' argument which controls CPU,
   kernel and tracepoint accesses (in this context, CPU, kernel and
   tracepoint have the same semantics as the perf_event_paranoid sysctl).
   Additionally, I added an 'open' type which is similar to
   perf_event_paranoid sysctl == 3 patch carried in Android and several other
   distros but was rejected in mainline [1] in 2016.

2. perf_event_alloc: This allocates a new security object for the event
   which stores the current SID within the event. It will be useful when
   the perf event's FD is passed through IPC to another process which may
   try to read the FD. Appropriate security checks will limit access.

3. perf_event_free: Called when the event is closed.

4. perf_event_read: Called from the read(2) system call path for the event.

5. perf_event_write: Called from the read(2) system call path for the event.

[1] https://lwn.net/Articles/696240/

Since Peter had suggest LSM hooks in 2016 [1], I am adding his
Suggested-by tag below.

To use this patch, we set the perf_event_paranoid sysctl to -1 and then
apply selinux checking as appropriate (default deny everything, and then
add policy rules to give access to domains that need it). In the future
we can remove the perf_event_paranoid sysctl altogether.

Suggested-by: Peter Zijlstra 
Cc: Peter Zijlstra 
Cc: rost...@goodmis.org
Cc: primi...@google.com
Cc: rsavit...@google.com
Cc: je...@google.com
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes (Google) 

---
 arch/x86/events/intel/bts.c |  5 +++
 arch/x86/events/intel/core.c|  5 +++
 arch/x86/events/intel/p4.c  |  5 +++
 include/linux/lsm_hooks.h   | 15 +++
 include/linux/perf_event.h  |  3 ++
 include/linux/security.h| 39 +++-
 include/uapi/linux/perf_event.h | 13 ++
 kernel/events/core.c| 59 +---
 kernel/trace/trace_event_perf.c | 15 ++-
 security/security.c | 33 ++
 security/selinux/hooks.c| 69 +
 security/selinux/include/classmap.h |  2 +
 security/selinux/include/objsec.h   |  6 ++-
 13 files changed, 259 insertions(+), 10 deletions(-)

diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c
index 5ee3fed881d3..9796fc094dad 100644
--- a/arch/x86/events/intel/bts.c
+++ b/arch/x86/events/intel/bts.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -553,6 +554,10 @@ static int bts_event_init(struct perf_event *event)
!capable(CAP_SYS_ADMIN))
return -EACCES;
 
+   ret = security_perf_event_open(>attr, PERF_SECURITY_KERNEL);
+   if (ret)
+   return ret;
+
if (x86_add_exclusive(x86_lbr_exclusive_bts))
return -EBUSY;
 
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 27ee47a7be66..75b6b9b239ae 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3318,6 +3319,10 @@ static int intel_pmu_hw_config(struct perf_event *event)
if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
return -EACCES;
 
+   ret = security_perf_event_open(>attr, PERF_SECURITY_CPU);
+   if (ret)
+   return ret;
+
event->hw.config |= ARCH_PERFMON_EVENTSEL_ANY;
 
return 0;
diff --git a/arch/x86/events/intel/p4.c b/arch/x86/events/intel/p4.c
index dee579efb2b2..6ac1a0328710 100644
--- a/arch/x86/events/intel/p4.c
+++ b/arch/x86/events/intel/p4.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
@@ -778,6 +779,10 @@ static int p4_validate_raw_event(struct perf_event *event)
if (p4_ht_active() && p4_event_bind_map[v].shared) {
if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
return -EACCES;
+
+