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 1862383 - Provide "domain_can_read_symlinks" boolean
Summary: Provide "domain_can_read_symlinks" boolean
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.2
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-31 10:08 UTC by g.danti
Modified: 2022-01-28 14:12 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-28 14:12:11 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description g.danti 2020-07-31 10:08:36 UTC 
Description of problem:
I have issue with selinux permission when relocating specific daemon data directory, and using symlink in the original location. It would be much more convenient if a "domain_can_read_symlinks" can provide the required lnk_read capability. It would be useful to can set it both globally (ie: lnk_read is granted to all domains) and per-domain (ie: httpd_can_read_symlinks").

Below, some issue examples are provided.

[MYSQL]
Lets consider moving /var/lib/mysql in a new, bigger volume.

After moving /var/lib/mysql in /data/lib/mysql and creating a symlink for the new location, I used semanage fcontext to add the relative equivalency rules. Moreover, I changed my.cnf to explicitly point to the new data dir and socket file. So far, so good.

When restarting apache, I noticed it can't connect to mysql. ausearch -m avc showed the following:
...
type=AVC msg=audit(1596055762.070:175569): avc:  denied  { read } for  pid=72946 comm="httpd" name="mysql" dev="sda2" ino=103 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:mysqld_db_t:s0 tclass=lnk_file permissive=0

The log above clearly states that httpd policy lacks lnk_read permission for mysqld_db_t type.

[MONGODB]
Another example, from relocating mongodb (this time on a CentOS 7 box):
semanage fcontext -a -e /var/lib/mongo /tank/graylog/var/lib/mongo
mv /var/lib/mongo /tank/graylog/var/lib/mongo
ln -s /tank/graylog/var/lib/mongo /var/lib/mongo
restorecon /var/lib/mongo
systemctl restart mongod

Result:
MongoDB does not start. Issuing "cat /var/log/audit/audit.log |
audit2allow" show the following error: "allow mongod_t
mongod_var_lib_t:lnk_file read;"

Indeed, sesearch can not find any permission to read mongod_var_lib_t links:
[root@localhost ~]# sesearch -A -s mongod_t | grep lnk_file | grep
mongod_var_lib_t

[VIRTLOGD]
Fixed via specific permission for lnk_read in BZ https://bugzilla.redhat.com/show_bug.cgi?id=1598593

Version-Release number of selected component (if applicable):
Any current RHEL/CentOS/Fedora selinux policy

How reproducible:
See above.

Steps to Reproduce:
See above.

Actual results:
Relocated services fail to start and/or other domains can not access their socket file.

Expected results:
Relocating services should be easier.

Additional info:
None.
Comment 1 g.danti 2020-08-01 17:55:16 UTC 
I would only add that on selinux.org mailing list and alternative approach was suggested: to let any domain normally operating on /var/lib to lnk_read any symlink labeled as var_lib_t (see here: https://lore.kernel.org/selinux/ypjl1rkrmpul.fsf@defensec.nl/). 
This would enable more domain to be reloated with the symlink approach, without needing a policy customization done via audit2allow and similar.
Comment 4 Zdenek Pytela 2020-11-10 18:45:25 UTC 
Hi,

After a discussion in our team, we are not going to allow permissions domain_can_read_symlinks. The alternative solution seems to be more viable, but it needs to be assessed for individual use cases and resolved not to break any existing functionality in RHEL 8. Please open a separate bz for every issue you deal with. Note in general a custom selinux policy is required whenever a significant change to default configuration is made.

Please also note this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution. If your issues are critical or in any way time sensitive, raise a ticket through the regular Red Hat support channels to ensure it receives proper attention and prioritization to assure a timely resolution.
Comment 5 g.danti 2020-11-10 21:42:06 UTC 
(In reply to Zdenek Pytela from comment #4)
> Hi,
> 
> After a discussion in our team, we are not going to allow permissions
> domain_can_read_symlinks. The alternative solution seems to be more viable,
> but it needs to be assessed for individual use cases and resolved not to
> break any existing functionality in RHEL 8. Please open a separate bz for
> every issue you deal with. Note in general a custom selinux policy is
> required whenever a significant change to default configuration is made.

Hi, above I posted 3 examples of services breaking when relocated. While I have no issue in opening a separate ticket for each of them, I would like to underscore that *many* services shows the same behavior. It seems impractical to manage each of these correlated issue via separate ticket. I think that sysadmins needs a more general approach - ie: one of the two detailed above. Otherwise the only solution is to customize the security policy via audit2allow (or to game the security policy as shown in the virtlogd example) ot to completely disable selinux, which is the worst possible outcome.

> Please also note this bug tracking system is not a mechanism for requesting
> support, and we are not able to guarantee the timeliness or suitability of a
> resolution. If your issues are critical or in any way time sensitive, raise
> a ticket through the regular Red Hat support channels to ensure it receives
> proper attention and prioritization to assure a timely resolution.

I understand how customize the security policy, so this is not a support request ticket. Rather, I opened it to let you know how difficult is to relocate a service. While I customize the policy, many other sysadmins will simply disable selinux.
Comment 6 Zdenek Pytela 2020-11-11 07:43:41 UTC 
Hi,

I understand and thank you for all your inputs and thoughts.
Comment 8 Zdenek Pytela 2022-01-28 14:12:11 UTC 
Based on outcomes of discussion in this bz and in the mailing list I am going to close this bz as WONTFIX.
Note You need to log in before you can comment on or make changes to this bug.