From: craig@rootwork.it (Craig Finch) Date: Thu, 21 Jan 2016 17:44:08 -0500 Subject: [refpolicy] Custom policy to allow logrotate to rotate OSSEC logs In-Reply-To: <56A14EE0.6000107@gmail.com> References: <56A14EE0.6000107@gmail.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com While searching the denial messages, I realized that we actually might have a different problem. Here is a typical denial: ---- time->Mon Jan 11 03:44:01 2016 type=SYSCALL msg=audit(1452501841.120:18607): arch=c000003e syscall=257 success=no exit=-13 a0=ffffffffffffff9c a1=7ffd42dbde90 a2=90800 a3=0 items=0 ppid=26196 pid=26198 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=993 sgid=0 fsgid=993 tty=(none) ses=178 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1452501841.120:18607): avc: denied { read } for pid=26198 comm="logrotate" name="logs" dev="dm-0" ino=25742482 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_t:s0 tclass=dir ---- I just noticed that the file context for this denial is actually var_t, not var_log_t. We were using the context var_log_t successfully last fall, but it appeared to stop working around Jan. 10, when the selinux-policy RPM was updated. We thought the problem was due to a policy update. I now suspect that the selinux context was not changed permanently, and reverted to the default context when the server was rebooted for a kernel update. After running: restorecon -R /var/ossec/logs/ The contexts are: drwxrwx---. ossec ossec system_u:object_r:var_t:s0 . dr-xr-x---. root ossec system_u:object_r:var_t:s0 .. -rw-rw-r--. ossec ossec system_u:object_r:var_log_t:s0 ossec.log What do we need to change to make this work? Craig On Thu, Jan 21, 2016 at 4:34 PM, Dominick Grift wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 01/21/2016 10:24 PM, Craig Finch wrote: > > I am using OSSEC to monitor system logs for possible intrusions and > > other errors on a CentOS 7 system, with SELinux set to "enforcing." > > OSSEC stores its logs in a non-standard location (/var/ossec/logs), > > and the default SELinux policies do not allow logrotate to rotate > > these logs. The default context for this directory is: > > > > drwxrwx---. ossec ossec system_u:object_r:var_t:s0 . > > dr-xr-x---. root ossec system_u:object_r:var_t:s0 .. > > -rw-rw-r--. ossec ossec system_u:object_r:var_log_t:s0 ossec.log > > > > In order to allow logrotate to rotate these logs, I changed the > > context of the log files to logrotate_t and created a custom > > SELinux module, which is shown at the end of this message. These > > changes allow the logs to be rotated. > > > > I am posting this solution to get feedback and to ensure that I > > have not accidentally created a security problem. Please let me > > know if you have any suggestions. > > > > logrotate_t is the type associated with the logrotate process. Types > that are for processes should not be associated with files. > > according to the policy [1], logrotate can rotate files associated > with type var_log_t. If this did not work for you then would you > please show us the relevant AVC denials of this event? > > [1] > https://github.com/TresysTechnology/refpolicy-contrib/blob/master/logrot > ate.te#L106 > > > > ------------- > > > > module ossec_logrotate 1.0.2; > > > > require { type fs_t; type logrotate_t; class dir { add_name write > > remove_name rename }; class file { create setattr rename unlink }; > > class filesystem associate; } > > > > #============= logrotate_t ============== allow logrotate_t > > fs_t:filesystem associate; allow logrotate_t self:dir { add_name > > write remove_name rename }; allow logrotate_t self:file { create > > setattr rename unlink }; > > > > -- Craig Finch Principal Consultant Rootwork InfoTech LLC Mobile: > > 321.209.8088 www.rootwork.it > > > > > > > > _______________________________________________ refpolicy mailing > > list refpolicy at oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > > > > > - -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 > Dominick Grift > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQGcBAEBCAAGBQJWoU7bAAoJECV0jlU3+Udp7ngMAJAhl3n9PJkTzPB45UBvH7pV > TITXQ/mwaK1VRq+Szm3+NeDmMBe8QSXU5e+GGk7G1Clr/qhhhjRg3YmOWndJqqjP > FYs3co1PJxEY03ZQdKrmS216qADL65ZGLBcUJu2N289N3LMt+gFwcLvB8McCG33H > 7aeFKnPbUptZG7pVk0VfNPi6X7BC1F4GYg+1t4931RPhuMAcnn/nmY+KCmUvdvde > 2IgQ7sAGPUH7vkjY6jCQoBrIIub2qsw4EGVtBM9UVOgNOnoQALATiwK1qERGA2od > oevs5I5FUjILDOulQlm6FWhiljfKTC6adxNR14wx+U/4UJapSCBcA4DrUKKdIdLh > CbC9EUaPJ9LCG5aWD7TTNgIUVh8OttqlH5Ew+UbcCQwss8n+xyl/HGptg9To1ad5 > n9YWPTRfk/um91B1ViOw/pltYOj65sjVUDIc6qs5DuzeMPyO6KXERzZvQgbEW5gi > sRNsv0efmLJowX8jrU/XAjP+HoyH/y1chZVdr8k1SQ== > =6iDZ > -----END PGP SIGNATURE----- > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy > -- Craig Finch Principal Consultant Rootwork InfoTech LLC Phone: 321.209.2447 Mobile: 321.209.8088 www.rootwork.it -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160121/68e99bae/attachment-0001.html