Re: [PATCH 3/3] tracing: Do not create directories if lockdown is in affect

Re: [PATCH 3/3] tracing: Do not create directories if lockdown is in affect

[Steven Rostedt]

I should have marked this for stable. The commit it fixes (see Fixes tag) is
in 5.4, and it appears this has yet to make it to 5.4 yet.

-- Steve


On Wed, Dec 04, 2019 at 09:05:02PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> 
> If lockdown is disabling tracing on boot up, it prevents the tracing files
> from even bering created. But when that happens, there's several places that
> will give a warning that the files were not created as that is usually a
> sign of a bug.
> 
> Add in strategic locations where a check is made to see if tracing is
> disabled by lockdown, and if it is, do not go further, and fail silently
> (but print that tracing is disabled by lockdown, without doing a WARN_ON()).
> 
> Cc: Matthew Garrett <mjg59@google.com>
> Fixes: 17911ff38aa5 ("tracing: Add locked_down checks to the open calls of files created for tracefs")
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
>  kernel/trace/ring_buffer.c |  6 ++++++
>  kernel/trace/trace.c       | 17 +++++++++++++++++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 66358d66c933..4bf050fcfe3b 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -11,6 +11,7 @@
>  #include <linux/trace_seq.h>
>  #include <linux/spinlock.h>
>  #include <linux/irq_work.h>
> +#include <linux/security.h>
>  #include <linux/uaccess.h>
>  #include <linux/hardirq.h>
>  #include <linux/kthread.h>	/* for self test */
> @@ -5068,6 +5069,11 @@ static __init int test_ringbuffer(void)
>  	int cpu;
>  	int ret = 0;
>  
> +	if (security_locked_down(LOCKDOWN_TRACEFS)) {
> +		pr_warning("Lockdown is enabled, skipping ring buffer tests\n");
> +		return 0;
> +	}
> +
>  	pr_info("Running ring buffer tests...\n");
>  
>  	buffer = ring_buffer_alloc(RB_TEST_BUFFER_SIZE, RB_FL_OVERWRITE);
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 02a23a6e5e00..23459d53d576 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -1888,6 +1888,12 @@ int __init register_tracer(struct tracer *type)
>  		return -1;
>  	}
>  
> +	if (security_locked_down(LOCKDOWN_TRACEFS)) {
> +		pr_warning("Can not register tracer %s due to lockdown\n",
> +			   type->name);
> +		return -EPERM;
> +	}
> +
>  	mutex_lock(&trace_types_lock);
>  
>  	tracing_selftest_running = true;
> @@ -8789,6 +8795,11 @@ struct dentry *tracing_init_dentry(void)
>  {
>  	struct trace_array *tr = &global_trace;
>  
> +	if (security_locked_down(LOCKDOWN_TRACEFS)) {
> +		pr_warning("Tracing disabled due to lockdown\n");
> +		return ERR_PTR(-EPERM);
> +	}
> +
>  	/* The top level trace array uses  NULL as parent */
>  	if (tr->dir)
>  		return NULL;
> @@ -9231,6 +9242,12 @@ __init static int tracer_alloc_buffers(void)
>  	int ring_buf_size;
>  	int ret = -ENOMEM;
>  
> +
> +	if (security_locked_down(LOCKDOWN_TRACEFS)) {
> +		pr_warning("Tracing disabled due to lockdown\n");
> +		return -EPERM;
> +	}
> +
>  	/*
>  	 * Make sure we don't accidently add more trace options
>  	 * than we have bits for.
> -- 
> 2.24.0
> 

Re: [PATCH 3/3] tracing: Do not create directories if lockdown is in affect

[Greg KH]

On Fri, Jan 10, 2020 at 11:31:05AM -0500, Steven Rostedt wrote:
> I should have marked this for stable. The commit it fixes (see Fixes tag) is
> in 5.4, and it appears this has yet to make it to 5.4 yet.
> 
> -- Steve
> 
> 
> On Wed, Dec 04, 2019 at 09:05:02PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> > 
> > If lockdown is disabling tracing on boot up, it prevents the tracing files
> > from even bering created. But when that happens, there's several places that
> > will give a warning that the files were not created as that is usually a
> > sign of a bug.
> > 
> > Add in strategic locations where a check is made to see if tracing is
> > disabled by lockdown, and if it is, do not go further, and fail silently
> > (but print that tracing is disabled by lockdown, without doing a WARN_ON()).
> > 
> > Cc: Matthew Garrett <mjg59@google.com>
> > Fixes: 17911ff38aa5 ("tracing: Add locked_down checks to the open calls of files created for tracefs")
> > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

Relying only on the Fixes: tag to get things picked up by stable is a
sure way to get it on the "slow, and maybe eventually, hopefully, it
might make it into stable" path :)

I have over 1000 patches right now in that "bucket" that need to be
checked to see if they are relevant for stable backporting, just since
5.4 was released.  I have automated a lot of it, but still, they require
manual review.

I'll go queue this up now, as it's simplest just to ask us to take it
after it hits Linus's tree :)

thanks,

greg k-h

Re: [PATCH 3/3] tracing: Do not create directories if lockdown is in affect

[Steven Rostedt]

On Fri, 10 Jan 2020 17:54:04 +0100
Greg KH <greg@kroah.com> wrote:

> Relying only on the Fixes: tag to get things picked up by stable is a
> sure way to get it on the "slow, and maybe eventually, hopefully, it
> might make it into stable" path :)

I've been numbed by all the AUTOSEL patches, where I tend to think
Fixes is becoming enough. That said, this particular patch, I thought
was going in the same release as what it fixed, which is why I never
added stable to it. :-/

> 
> I have over 1000 patches right now in that "bucket" that need to be
> checked to see if they are relevant for stable backporting, just since
> 5.4 was released.  I have automated a lot of it, but still, they require
> manual review.
> 
> I'll go queue this up now, as it's simplest just to ask us to take it
> after it hits Linus's tree :)

Again, I thought the AUTOSEL would pick it up, as it seems to pick
other patches I don't intend on going to stable quickly ;-)

-- Steve