Bug 1955839

Summary: SELinux prevents systemd from 'read' accesses on any user's file
Product: [Fedora] Fedora Reporter: ivanov17 <ivanov17>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 33CC: dwalsh, grepl.miroslav, lvrabec, mmalik, omosnace, plautrba, vmojzis, zpytela
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description ivanov17 2021-05-01 00:00:06 UTC
Description of problem:

I need in monitoring of user's file modifications. I've created a pair of systemd units, a .path unit with 'PathModified' option for monitoring and a .service file for execution of a program. But SELinux prevents systemd from reading a user's file, and it makes the file monitoring not possible. It seems a very strange since it breaks the systemd functionality. 

Originally I found the problem on CentOS 8.3. SELinux is prevented systemd from reading files of a system user, in my case it is the owner of git repositories. It blocks a monitoring of file modifications e.g. in the .git/refs directory, and makes .path units useless. Git hooks are not suitable for me, because a program must be executed by another system user after file's modification.

I have not tested it with Fedora, but it seems that results should be similar. At least I don't see the difference in a SELinux behavior regarding systemd attempts to read files of a regular user on Fedora or a system user on CentOS.  


Version-Release number of selected component (if applicable):

# rpm -q selinux-policy selinux-policy-targeted
selinux-policy-3.14.6-36.fc33.noarch
selinux-policy-targeted-3.14.6-36.fc33.noarch


How reproducible: always


Steps to Reproduce:

1. Create a systemd .path unit that monitors user's file changes

# /etc/systemd/system/test-monitoring.path
[Unit]
Description=Test File Monitoring
[Path]
PathModified=/home/user/testfile
Unit=test-monitoring.service
[Install]
WantedBy=paths.target

2. Create a systemd .service unit that does something, e.g. displays a wall message

# /etc/systemd/system/test-monitoring.service
[Unit]
Description=Wall Message
[Service]
Type=oneshot
ExecStart=/usr/bin/wall -t 1 -n "SUCCESS"

3. Start the systemd .path unit

# systemctl start test-monitoring.path

4. Create the file in user's home directory and modify it

$ touch /home/user/testfile
$ echo "lorem ipsum" > /home/user/testfile
$ echo "lorem ipsum dolor sit amet" >> /home/user/testfile


Actual results:

# ausearch -f testfile
----
time->Fri Apr 30 10:51:36 2021
type=AVC msg=audit(1619769096.222:1425): avc:  denied  { read } for  pid=1 comm="systemd" name="testfile" dev="dm-2" ino=8796315 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0
----
time->Fri Apr 30 10:51:40 2021
type=AVC msg=audit(1619769100.008:1429): avc:  denied  { read } for  pid=1 comm="systemd" name="testfile" dev="dm-2" ino=8796315 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0


Expected results:

SELinux shouldn't block the systemd functionality

Additional info:

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

# uname -r
5.11.16-200.fc33.x86_64

Comment 1 ivanov17 2021-05-02 07:05:55 UTC
Hmm ... It seems in the case of git repositories the point is that they placed in /var/lib/git directory labeled with git_sys_content_t. 
A process labeled with init_t can manage files labeled with var_lib_t, but files, labeled as git_sys_content_t aren't its managed files.

https://www.mankier.com/8/init_selinux#Managed_Files

# semanage fcontext -l | grep "/var/lib/git"
/var/lib/git(/.*)?                                 all files          system_u:object_r:git_sys_content_t:s0 
/var/lib/gitolite(3)?(/.*)?                        all files          system_u:object_r:gitosis_var_lib_t:s0 
/var/lib/gitolite/\.ssh(/.*)?                      all files          system_u:object_r:ssh_home_t:s0 
/var/lib/gitolite3/\.ssh(/.*)?                     all files          system_u:object_r:ssh_home_t:s0 
/var/lib/gitosis(/.*)?                             all files          system_u:object_r:gitosis_var_lib_t:s0

# sesearch -s init_t -t git_sys_content_t -c file -A
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow init_t file_type:file { getattr relabelfrom relabelto };
allow init_t non_security_file_type:file mounton; [ init_create_dirs ]:True

# sesearch -s init_t -t var_lib_t -c file -A
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow init_t file_type:file { getattr relabelfrom relabelto };
allow init_t mountpoint:file { getattr mounton };
allow init_t non_security_file_type:file mounton; [ init_create_dirs ]:True
allow init_t var_lib_t:file { append create getattr ioctl link lock open read rename setattr unlink write };

I got the same results both on CentOS 8 and Fedora 33.