Bug 1306422 - BUG: /sys/kernel/debug/tracing is not labeled correctly with SELinux
BUG: /sys/kernel/debug/tracing is not labeled correctly with SELinux
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Paul Moore
Fedora Extras Quality Assurance
: FutureFeature, Reproducer
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-10 14:42 EST by Petr Lautrbach
Modified: 2017-06-15 14:03 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-15 14:03:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Lautrbach 2016-02-10 14:42:21 EST
Description of problem:

# ls -lZd /sys/kernel/debug/tracing                                                                                                  
drwx------. 7 root root system_u:object_r:unlabeled_t:s0 0 Feb  9 16:36 /sys/kernel/debug/tracing

# uname -a
Linux fedora23.localdomain 4.3.5-300.fc23.x86_64 #1 SMP Mon Feb 1 03:18:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Comment 1 Josh Boyer 2016-02-10 14:57:10 EST
Why is that a problem?  What should it be labeled?  Also, how is it a kernel problem, given that the SELinux policy is what should be setting the labels?

As an aside, anything under /sys/kernel/debug/ is literally for debugging and may or may not be present at any given time.
Comment 2 Paul Moore 2016-02-11 04:22:27 EST
(In reply to Josh Boyer from comment #1)
> Why is that a problem?

With very few exceptions, unlabeled_t is almost always wrong; it means that we failed to label an entity (subj or obj) when it was created and that is a Very Bad Thing for label based security systems.

> What should it be labeled?

I can't tell you what it should be labeled off the top of my head right now (heading to the airport in a few minutes), but I can tell you it shouldn't be unlabeled_t.

A generic sysfs type, or kernel_t, might be reasonable labels, but depending on how the policy is written there could be other, better options.

> Also, how is it a kernel problem, given that the SELinux policy is what
> should be setting the labels?

The kernel always sets the labels on system entities using the configuration provided by the SELinux security policy loaded into the kernel.  You can't trust userspace to set security labels for many reasons; setting labels and enforcing the security policy needs to be done in the kernel.

Careful readers will note that there are exceptions to the above statement which we call "userspace object managers"; this is a good point but a better explanation is beyond the scope of this BZ and this comment.
 
> As an aside, anything under /sys/kernel/debug/ is literally for debugging
> and may or may not be present at any given time.

That isn't an excuse for not doing things correctly.  What might be temporary on one system, might be in production on another.  We can advise users on best practices, but ultimately it is their decision and we need to support their choices the best we can.
Comment 3 Josh Boyer 2016-02-11 06:47:00 EST
(In reply to Paul Moore from comment #2)
> (In reply to Josh Boyer from comment #1)
> > Why is that a problem?
> 
> With very few exceptions, unlabeled_t is almost always wrong; it means that
> we failed to label an entity (subj or obj) when it was created and that is a
> Very Bad Thing for label based security systems.

Yes, sure.  I wasn't saying it was labeled correctly.  I was asking what problem it actually causes.  The original bug report is pretty sketchy on details.  I want to know if something was broken and the reporter tracked it down to this, or if it was something they just noticed.

> > Also, how is it a kernel problem, given that the SELinux policy is what
> > should be setting the labels?
> 
> The kernel always sets the labels on system entities using the configuration
> provided by the SELinux security policy loaded into the kernel.  You can't
> trust userspace to set security labels for many reasons; setting labels and
> enforcing the security policy needs to be done in the kernel.

Yeah, I had it backwards in my head for some reason.  This is of course correct.

> Careful readers will note that there are exceptions to the above statement
> which we call "userspace object managers"; this is a good point but a better
> explanation is beyond the scope of this BZ and this comment.
>  
> > As an aside, anything under /sys/kernel/debug/ is literally for debugging
> > and may or may not be present at any given time.
> 
> That isn't an excuse for not doing things correctly.  What might be
> temporary on one system, might be in production on another.  We can advise
> users on best practices, but ultimately it is their decision and we need to
> support their choices the best we can.

I wasn't making an excuse.  Again, the original report has zero details other than "this is labeled weird".  I cannot begin to understand why it matters to the reporter, so I was making an aside observation in hopes it would actually give me more details.

You seem to have a handle on it.  I'll leave you to it.
Comment 4 Petr Lautrbach 2016-02-11 06:53:41 EST
(In reply to Josh Boyer from comment #3)
> (In reply to Paul Moore from comment #2)
> > (In reply to Josh Boyer from comment #1)
> > > Why is that a problem?
> > 
> > With very few exceptions, unlabeled_t is almost always wrong; it means that
> > we failed to label an entity (subj or obj) when it was created and that is a
> > Very Bad Thing for label based security systems.
> 
> Yes, sure.  I wasn't saying it was labeled correctly.  I was asking what
> problem it actually causes.  The original bug report is pretty sketchy on
> details.  I want to know if something was broken and the reporter tracked it
> down to this, or if it was something they just noticed.

I'm sorry for the briefness of the report. I've hit to this issue when I was working on other problem and found AVCs  denials with unlabeled_t in audit.log.

Paul asked me to file a bug so he could investigate it. That's why I assigned this bug directly to him.

I'll try to provide more information next time.
Comment 5 Paul Moore 2016-02-12 11:16:59 EST
I wouldn't fault Petr, as he mentioned in comment #4, he did exactly as I asked (thanks again Petr).  This was something he noticed and we both agreed it was worth investigating so I asked him to file a BZ so we/me wouldn't lose this issue.
Comment 6 Paul Moore 2017-06-15 14:03:51 EDT
This should be fixed now, closing this BZ.

 # uname -r                                                    
 4.12.0-0.rc5.git0.1.1.secnext.fc27.x86_64
 # ls -ldZ /sys/kernel/debug/tracing                         
 drwx------. 8 root root system_u:object_r:tracefs_t:s0 0 Jun 15 14:02 
  /sys/kernel/debug/tracing

Note You need to log in before you can comment on or make changes to this bug.