[SERVER-69819] SELinux denial following log rotation Created: 20/Sep/22  Updated: 16/Nov/23

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: INVADE International Ltd Assignee: Backlog - Security Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-36251 change logfile permissions. Closed
Assigned Teams:
Server Security
Operating System: ALL
Steps To Reproduce:

kill -USR1 {PID}

Sprint: Security 2022-10-17, Security 2022-10-31, Security 2022-11-14, Security 2022-11-28, Security 2022-12-12, Security 2022-12-26, Security 2023-01-09, Security 2023-01-23, Security 2023-02-06, Security 2023-04-03, Security 2023-06-12, Security 2023-06-26, Security 2023-07-10, Security 2023-07-24, Security 2023-08-07, Security 2023-08-21, Security 2023-09-04, Security 2023-09-18, Security 2023-10-02, Security 2023-10-16, Security 2023-10-30, Security 2023-11-13
Participants:

 Description   

Hi.

MongoDB 6.0 running on Rocky Linux 8.

We have noticed that the MongoDB server process is denied "write" access to the log file after it is rotated, as per this documentation:

https://www.mongodb.com/docs/manual/tutorial/rotate-log-files/#forcing-a-log-rotation-with-sigusr1

Restarting the mongod.service systemd unit does not produce the same denial.

It looks like the mongod process is requesting "write" access after the "kill", instead of "append", and being denied access because it has not been granted this permission.

MongoDB 5.0 running on Rocky Linux 8 is OK.

Additional information:

sudo ausearch -m avc
time->Tue Sep 20 03:46:01 2022
type=PROCTITLE msg=audit(1663641961.899:759879): proctitle=2F7573722F62696E2F6D6F6E676F64002D66002F6574632F6D6F6E676F642E636F6E66
type=PATH msg=audit(1663641961.899:759879): item=1 name="/var/log/mongodb/mongod.log" inode=8440224 dev=fd:03 mode=0100640 ouid=993 ogid=990 rdev=00:00 obj=system_u:object_r:mongod_log_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1663641961.899:759879): item=0 name="/var/log/mongodb/" inode=8440193 dev=fd:03 mode=040755 ouid=993 ogid=990 rdev=00:00 obj=system_u:object_r:mongod_log_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1663641961.899:759879): cwd="/"
type=SYSCALL msg=audit(1663641961.899:759879): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55d9d0d28a20 a2=241 a3=1b6 items=2 ppid=1 pid=1565 auid=4294967295 uid=993 gid=990 euid=993 suid=993 fsuid=993 egid=990 sgid=990 fsgid=990 tty=(none) ses=4294967295 comm="SignalHandler" exe="/usr/bin/mongod" subj=system_u:system_r:mongod_t:s0 key=(null)
type=AVC msg=audit(1663641961.899:759879): avc:  denied  { write } for  pid=1565 comm="SignalHandler" name="mongod.log" dev="dm-3" ino=8440224 scontext=system_u:system_r:mongod_t:s0 tcontext=system_u:object_r:mongod_log_t:s0 tclass=file permissive=0

ps -ef | grep mongo
system_u:system_r:mongod_t:s0 mongod 1565 1 2 Sep15 ? 03:17:55 /usr/bin/mongod -f /etc/mongod.conf
 
sudo lsof -p 1565 | grep mongod.log
mongod 1565 mongod 6w REG 253,3 32082779 8440194 /var/log/mongodb/mongod.log-20220915

sudo semanage fcontext --list | grep "/var/log/mongodb"
/var/log/mongodb(/.*)?                             all files          system_u:object_r:mongod_log_t:s0

sudo sesearch --allow --source mongod_t --target mongod_log_t --class file
allow daemon logfile:file { append getattr ioctl lock };
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow mongod_t mongod_log_t:file { append create getattr ioctl lock open rename setattr };

{{}}



 Comments   
Comment by Adam Rayner [ 03/Aug/23 ]

Hi third.line@invade.net, we assess and prioritize SELinux support improvements on an ongoing basis, along with all other server improvements. Cheers!

Comment by INVADE International Ltd [ 02/Aug/23 ]

Hi.

As this issue has now been open for nearly a year, can I ask how often you assess the iterations of your SELinux support?

Thanks.

Comment by Adam Rayner [ 01/Aug/23 ]

Hi third.line@invade.net, thanks again for bringing this to our attention.

As there appears to be a workaround, I am moving this to our backlog and we will assess a permanent fix in the next iteration of our SELinux support.

Comment by INVADE International Ltd [ 04/Oct/22 ]

Hi.

I'm not sure that issue is related as it is referring the the file permissions of the log files. We want to keep the default file permissions.

This is a SELinux "write" denial. The options as I see it are:

  1. Change the code so that the log file is written to using "append" instead of "write".
  2. Add "write" access to your policy:
    https://github.com/mongodb/mongodb-selinux/blob/master/selinux/mongodb.te

Based on:
https://github.com/SELinuxProject/refpolicy/blob/master/policy/support/file_patterns.spt
and:
https://github.com/SELinuxProject/refpolicy/blob/master/policy/support/obj_perm_sets.spt

I believe this would mean adding either:
write_file_perms(mongod_t, mongod_log_t, mongod_log_t)
or:
rw_file_perms(mongod_t, mongod_log_t, mongod_log_t)

Comment by Yuan Fang [ 03/Oct/22 ]

Hi third.line@invade.net,

Thank you for reporting this issue. While I don't have a certain answer for this right now, from the description you provided, it seems similar to SERVER-36251.

Can you check and compare the file permissions of the closed log file and the new log file, and see if you agree this issue is the same as SERVER-36251? If so, you can instruct MongoDB log rotation to honor the system umask via the honorSystemUmask server parameter. Otherwise, please let us know.

Regards,
Yuan

Comment by INVADE International Ltd [ 03/Oct/22 ]

Just for info. We have temporarily added the following policy to resolve the problem:

 

 
module mongodb-test 1.0;
 
require {
	type mongod_t;
	type mongod_log_t;
	class file write;
}
 
#============= mongod_t ==============
allow mongod_t mongod_log_t:file write;

 

 

Generated at Thu Feb 08 06:14:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.