Bug 1470680 - "Missing type enforcement (TE) allow rule." related to httpd service
"Missing type enforcement (TE) allow rule." related to httpd service
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
7.1
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: Lukas Vrabec
Milos Malik
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-13 08:54 EDT by Marek Grapiniak
Modified: 2017-08-01 05:01 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-31 10:19:37 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 Marek Grapiniak 2017-07-13 08:54:41 EDT
Description of problem:


Version-Release number of selected component (if applicable):
selinux-policy.noarch          3.13.1-102.el7_3.16 @rhui-rhel-7-server-rhui-rpms
selinux-policy-targeted.noarch 3.13.1-102.el7_3.16 @rhui-rhel-7-server-rhui-rpms


How reproducible:
Installed
httpd.x86_64                   2.4.6-45.el7_3.4    @rhui-rhel-7-server-rhui-rpms

Steps to Reproduce:
1. Run httpd
2. check out the audit log
audit2why < /var/log/audit/audit.log
3. type=AVC msg=audit(1498038786.617:9344985): avc:  denied  { read } for  pid=31051 comm="httpd" name="content" dev="sdc" ino=11121 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=lnk_file

        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.


Actual results:
- High CPU usage
- audit.log filled with selinux errors above

Expected results: 
httpd not to through SElinux related warnings  


Additional info:
To mitigate the issue:
- Ran:
ausearch -c 'httpd' --raw | audit2allow -M my-httpd
- followed by:
semodule -i my-httpd.pp

Regards,
Marek
Comment 2 Milos Malik 2017-07-13 09:27:54 EDT
Could you please answer following questions?
 * Where is the content symlink located? 
 * Where does the content symlink point to?

The default_t label is wrong.
Comment 3 Marek Grapiniak 2017-07-13 10:52:30 EDT
(In reply to Milos Malik from comment #2)
> Could you please answer following questions?
>  * Where is the content symlink located? 
>  * Where does the content symlink point to?
> 
> The default_t label is wrong.

Hi, Milos

content symlink is located in a root directory
lrwxrwxrwx.   1 root root     5 Sep 22  2015 content -> /apps
->
drwxr-xr-x.   7 root root  4096 Aug 31  2016 apps

Nothing has changed really and issue started to occur after installing OS updates around 12th of June 2017th.

Regards,
Marek
Comment 4 Marek Grapiniak 2017-07-17 05:05:11 EDT
(In reply to Milos Malik from comment #2)
> Could you please answer following questions?
>  * Where is the content symlink located? 
>  * Where does the content symlink point to?
> 
> The default_t label is wrong.

What should be the correct label ?

BR,
Marek
Comment 5 Lukas Vrabec 2017-07-17 06:53:52 EDT
Marek, 

Correct label is: httpd_sys_content_t

you can setup right label using command semanage. 

THanks,
Lukas.
Comment 6 Marek Grapiniak 2017-07-24 09:43:07 EDT
(In reply to Lukas Vrabec from comment #5)
> Marek, 
> 
> Correct label is: httpd_sys_content_t
> 
> you can setup right label using command semanage. 
> 
> THanks,
> Lukas.

Hi Lukas,

Here is the output of semanage fcontext -l on my /apps directory

[root@invgb3vldisptch01 ~]# semanage fcontext -l |grep "/apps/"
/apps/cache(/.*)?                                  all files          system_u:object_r:httpd_sys_rw_content_t:s0
/apps/logs(/.*)?                                   all files          system_u:object_r:httpd_log_t:s0

Also I have a symlink /content created to /apps and within Apache config there are references to /content and thus the error message show up.

I would say the same fcontext rules should be applied for /content/cache* and /content/logs* via semanage.

Please advise if that is a valid approach.
Comment 7 Milos Malik 2017-07-24 09:50:51 EDT
What is the output of following command?

# matchpathcon /content  /apps
Comment 8 Marek Grapiniak 2017-07-26 05:01:29 EDT
They do match:

/content        system_u:object_r:default_t:s0
/apps           system_u:object_r:default_t:s0
Comment 9 Marek Grapiniak 2017-07-26 05:36:24 EDT
"I would say the same fcontext rules should be applied for /content/cache* and /content/logs* via semanage."

I have just checked and it looks like fcontext match for above locations but not sure if that was a result of the workaround I mentioned before or not. Se below:

"Additional info:
To mitigate the issue:
- Ran:
ausearch -c 'httpd' --raw | audit2allow -M my-httpd
- followed by:
semodule -i my-httpd.pp"
Comment 10 Miroslav Grepl 2017-07-27 05:36:39 EDT
We will need to setup also labeling for the top level /apps  directory.

Marek,
could you please run

# semanage fcontext -a -t "var_t" "/content(/.*)?" 
# semanage fcontext -a -t "var_t"  "/apps(/.*)?"
# restorecon -R -v /apps /content

to see if it works.
Comment 11 Marek Grapiniak 2017-07-28 09:26:57 EDT
I will give it a go and report shortly.

Thx.
Comment 12 Miroslav Grepl 2017-07-31 10:19:37 EDT
(In reply to Marek Grapiniak from comment #11)
> I will give it a go and report shortly.
> 
> Thx.

Ok. Please reopen the bug if it does not work.

Thank you Marek.

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