Bug 1862383

Summary: Provide "domain_can_read_symlinks" boolean
Product: Red Hat Enterprise Linux 8 Reporter: g.danti
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED WONTFIX QA Contact: Milos Malik <mmalik>
Severity: low Docs Contact:
Priority: low    
Version: 8.2CC: g.danti, laurent.rineau__fedora, lvrabec, mmalik, plautrba, ssekidde
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-01-28 14:12:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.