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.
-------------
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
http://www.rootwork.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160121/667abdb6/attachment.html
-----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 http://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-----
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 <[email protected]>
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 http://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
http://www.rootwork.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20160121/68e99bae/attachment-0001.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 01/21/2016 11:44 PM, Craig Finch wrote:
> 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
This should do it:
semanage fcontext -a -t var_log_t "/var/ossec/logs(/.*)?"
restorecon -R -v -F /var/ossec/logs
>
> ---- 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
> <[email protected]> wrote:
>
> 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/logr
ot
>
>
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 http://www.rootwork.it
>>>>
>>>>
>>>>
>>>> _______________________________________________ refpolicy
>>>> mailing list refpolicy at oss.tresys.com
>>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>>
>
>
>> _______________________________________________ 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
iQGcBAEBCAAGBQJWoeAcAAoJECV0jlU3+UdpYpYMAKjAMRWcYd7LQ0Zxl9iDgYGx
J6lYpM1mOI2qm1jGf2jzCjcAUTIRHxDUMABBtCqeesRE6iq+Q6m6OQqxShAeYFFt
N6xHviu8dLlglHgKjdEbeEKq7A97fx7gTDgzy/zdT2T2vmOYw1HPD9Q03fitT5Vl
gn3+9RLwsieNtcQftexbj3t6m+lTWQqAFFAwcd2QbcbYJpqJKJOCWJi8TiLz2mmV
qgungt/FDxQAUcS/cwIlF+AfQmG9cSS2LffcIpIoCY7Q6qwEbgpaW9ndmkpCHRhw
tbp1ByLS8qCouJKt1PEkn9HNyyrC+rFhgOKYdMAUf0PNSjUCkwBxEgwW/UNOBQb+
OhDvhuyz6F7S4b5yl6Ow/lYUb7cankr7TFb+8yefU5+YWdVuDt7lKXCGAcfm1Bp9
wMeqwWD1K5eN2aCuKUMQBt3uh2eVPvle1aJz9g4QqEW03bl3u+uwFvBkkLqJBLEZ
OjoRtvZYQ+2b8UUkJoyMmdKPhUURu/cHOBFUXi4eDw==
=mBzi
-----END PGP SIGNATURE-----