RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1470680 - "Missing type enforcement (TE) allow rule." related to httpd service
Summary: "Missing type enforcement (TE) allow rule." related to httpd service
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.1
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-13 12:54 UTC by Marek Grapiniak
Modified: 2017-08-01 09:01 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-31 14:19:37 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Marek Grapiniak 2017-07-13 12:54:41 UTC 
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 13:27:54 UTC 
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 14:52:30 UTC 
(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 09:05:11 UTC 
(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 10:53:52 UTC 
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 13:43:07 UTC 
(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 13:50:51 UTC 
What is the output of following command?

# matchpathcon /content  /apps
Comment 8 Marek Grapiniak 2017-07-26 09:01:29 UTC 
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 09:36:24 UTC 
"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 09:36:39 UTC 
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 13:26:57 UTC 
I will give it a go and report shortly.

Thx.
Comment 12 Miroslav Grepl 2017-07-31 14:19:37 UTC 
(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.