On Thursday, August 21, 2014 12:00:03 centos-request@centos.org wrote:
Re: [CentOS] SELinux vs. logwatch and virsh From: Daniel J Walsh dwalsh@redhat.com To: CentOS mailing list centos@centos.org
On 08/18/2014 02:13 PM, Bill Gee wrote:
Hi Dan -
"ausearch -m avc -ts recent" produces no output. If I run it as "ausearch -f virsh" then it produces output similar to this. Each day's run of logwatch produces three of these audit log entries. The a1 and a2 values are different for each entry, but everything else is the same.
=============== time->Mon Aug 18 03:21:03 2014 type=SYSCALL msg=audit(1408350063.257:7492): arch=c000003e syscall=21 success=no exit=-13 a0=11ee230 a1=4 a2=7fff722837b0 a3=7fff72283640 items=0 ppid=2815 pid=2816 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=981 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408350063.257:7492): avc: denied { read } for pid=2816 comm="bash" name="virsh" dev="dm-0" ino=135911290 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virsh_exec_t:s0 tclass=file ===============
I thought about using audit2allow as you suggest. The problem is then I don't really know what change is required. What exactly will it do? And is there a guarantee that it will work?
logwatch is executing virsh probably to communicate with libvirt to rotate logs or something. You can look in /etc/logrotate.d for a script with virsh to tell you what the command is trying to do.
Hi Dan -
I know EXACTLY what virsh is being called for. I wrote the script! It has nothing to do with logrotate. I want virsh to tell logwatch what the status is of all virtual machines running on the host. Logwatch will then include that in its daily summary report. SELinux is getting in the way.
Regards - Bill Gee
On 08/21/2014 10:03 AM, Bill Gee wrote:
On Thursday, August 21, 2014 12:00:03 centos-request@centos.org wrote:
Re: [CentOS] SELinux vs. logwatch and virsh From: Daniel J Walsh dwalsh@redhat.com To: CentOS mailing list centos@centos.org
On 08/18/2014 02:13 PM, Bill Gee wrote:
Hi Dan -
"ausearch -m avc -ts recent" produces no output. If I run it as "ausearch -f virsh" then it produces output similar to this. Each day's run of logwatch produces three of these audit log entries. The a1 and a2 values are different for each entry, but everything else is the same.
=============== time->Mon Aug 18 03:21:03 2014 type=SYSCALL msg=audit(1408350063.257:7492): arch=c000003e syscall=21 success=no exit=-13 a0=11ee230 a1=4 a2=7fff722837b0 a3=7fff72283640 items=0 ppid=2815 pid=2816 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=981 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408350063.257:7492): avc: denied { read } for pid=2816 comm="bash" name="virsh" dev="dm-0" ino=135911290 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virsh_exec_t:s0 tclass=file ===============
I thought about using audit2allow as you suggest. The problem is then I don't really know what change is required. What exactly will it do? And is there a guarantee that it will work?
logwatch is executing virsh probably to communicate with libvirt to rotate logs or something. You can look in /etc/logrotate.d for a script with virsh to tell you what the command is trying to do.
Hi Dan -
I know EXACTLY what virsh is being called for. I wrote the script! It has nothing to do with logrotate. I want virsh to tell logwatch what the status is of all virtual machines running on the host. Logwatch will then include that in its daily summary report. SELinux is getting in the way.
Regards - Bill Gee _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Well logrotate is calling the script, and you just need to add the allow rules to allow logrotate to execute the script and communicate with libvirt. Or you need to run the script in a separate cron job to collect the data before the logrotate script runs.
On Friday, August 22, 2014 08:50:26 Daniel J Walsh wrote:
On 08/21/2014 10:03 AM, Bill Gee wrote:
On Thursday, August 21, 2014 12:00:03 centos-request@centos.org wrote:
Re: [CentOS] SELinux vs. logwatch and virsh From: Daniel J Walsh dwalsh@redhat.com To: CentOS mailing list centos@centos.org
On 08/18/2014 02:13 PM, Bill Gee wrote:
Hi Dan -
"ausearch -m avc -ts recent" produces no output. If I run it as "ausearch -f virsh" then it produces output similar to this. Each day's run of logwatch produces three of these audit log entries. The a1 and a2 values are different for each entry, but everything else is the same.
=============== time->Mon Aug 18 03:21:03 2014 type=SYSCALL msg=audit(1408350063.257:7492): arch=c000003e syscall=21 success=no exit=-13 a0=11ee230 a1=4 a2=7fff722837b0 a3=7fff72283640 items=0 ppid=2815 pid=2816 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=981 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408350063.257:7492): avc: denied { read } for pid=2816 comm="bash" name="virsh" dev="dm-0" ino=135911290 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virsh_exec_t:s0 tclass=file ===============
I thought about using audit2allow as you suggest. The problem is then I don't really know what change is required. What exactly will it do? And is there a guarantee that it will work?
logwatch is executing virsh probably to communicate with libvirt to rotate logs or something. You can look in /etc/logrotate.d for a script with virsh to tell you what the command is trying to do.
Hi Dan -
I know EXACTLY what virsh is being called for. I wrote the script! It has nothing to do with logrotate. I want virsh to tell logwatch what the status is of all virtual machines running on the host. Logwatch will then include that in its daily summary report. SELinux is getting in the way.
Regards - Bill Gee _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Well logrotate is calling the script, and you just need to add the allow rules to allow logrotate to execute the script and communicate with libvirt. Or you need to run the script in a separate cron job to collect the data before the logrotate script runs.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Dan -
Oops, I screwed up the subject line on the last posting. Hopefully corrected with this message.
Comment - I changed my configuration so that virsh is run by a script in cron.daily rather than being called from logwatch. It saves output to a file in /tmp. Logwatch was changed to simply "cat" the file. However, this STILL produces an SELinux violation. I am not any closer to the goal.
Question - How do I add an "allow" rule to SELinux? What exactly is to be allowed and how is SELinux told to do it?
Here is what ausearch finds:
===================== time->Sat Aug 23 03:06:04 2014 type=SYSCALL msg=audit(1408781164.014:1373): arch=c000003e syscall=2 success=no exit=-13 a0=7fffb24e3da6 a1=0 a2=1fffffffffff0000 a3=7fffb24e31d0 items=0 ppid=25741 pid=25742 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=127 comm="cat" exe="/usr/bin/cat" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408781164.014:1373): avc: denied { open } for pid=25742 comm="cat" path="/tmp/libvirt-status" dev="dm-0" ino=768471 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
=====================
Observation - My original idea on this is to have logwatch execute virsh directly. I know it is possible to make that work. The same computer has two other logwatch items that I created. One of them runs uptime and the other runs sensors. Both work perfectly. I see that the uptime and sensors programs are set for SELinux type=bin_t, which is not the same as what virsh is set for. I think what I need to do is figure out how to ADD (not replace) a new type on the virsh program.
Thanks - Bill Gee
On 08/23/2014 10:45 AM, Bill Gee wrote:
On Friday, August 22, 2014 08:50:26 Daniel J Walsh wrote:
On 08/21/2014 10:03 AM, Bill Gee wrote:
On Thursday, August 21, 2014 12:00:03 centos-request@centos.org wrote:
Re: [CentOS] SELinux vs. logwatch and virsh From: Daniel J Walsh dwalsh@redhat.com To: CentOS mailing list centos@centos.org
On 08/18/2014 02:13 PM, Bill Gee wrote:
Hi Dan -
"ausearch -m avc -ts recent" produces no output. If I run it as "ausearch -f virsh" then it produces output similar to this. Each day's run of logwatch produces three of these audit log entries. The a1 and a2 values are different for each entry, but everything else is the same.
=============== time->Mon Aug 18 03:21:03 2014 type=SYSCALL msg=audit(1408350063.257:7492): arch=c000003e syscall=21 success=no exit=-13 a0=11ee230 a1=4 a2=7fff722837b0 a3=7fff72283640 items=0 ppid=2815 pid=2816 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=981 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408350063.257:7492): avc: denied { read } for pid=2816 comm="bash" name="virsh" dev="dm-0" ino=135911290 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virsh_exec_t:s0 tclass=file ===============
I thought about using audit2allow as you suggest. The problem is then I don't really know what change is required. What exactly will it do? And is there a guarantee that it will work?
logwatch is executing virsh probably to communicate with libvirt to rotate logs or something. You can look in /etc/logrotate.d for a script with virsh to tell you what the command is trying to do.
Hi Dan -
I know EXACTLY what virsh is being called for. I wrote the script! It has nothing to do with logrotate. I want virsh to tell logwatch what the status is of all virtual machines running on the host. Logwatch will then include that in its daily summary report. SELinux is getting in the way.
Regards - Bill Gee _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Well logrotate is calling the script, and you just need to add the allow rules to allow logrotate to execute the script and communicate with libvirt. Or you need to run the script in a separate cron job to collect the data before the logrotate script runs.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Dan -
Oops, I screwed up the subject line on the last posting. Hopefully corrected with this message.
Comment - I changed my configuration so that virsh is run by a script in cron.daily rather than being called from logwatch. It saves output to a file in /tmp. Logwatch was changed to simply "cat" the file. However, this STILL produces an SELinux violation. I am not any closer to the goal.
Question - How do I add an "allow" rule to SELinux? What exactly is to be allowed and how is SELinux told to do it?
Here is what ausearch finds:
===================== time->Sat Aug 23 03:06:04 2014 type=SYSCALL msg=audit(1408781164.014:1373): arch=c000003e syscall=2 success=no exit=-13 a0=7fffb24e3da6 a1=0 a2=1fffffffffff0000 a3=7fffb24e31d0 items=0 ppid=25741 pid=25742 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=127 comm="cat" exe="/usr/bin/cat" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408781164.014:1373): avc: denied { open } for pid=25742 comm="cat" path="/tmp/libvirt-status" dev="dm-0" ino=768471 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
=====================
Observation - My original idea on this is to have logwatch execute virsh directly. I know it is possible to make that work. The same computer has two other logwatch items that I created. One of them runs uptime and the other runs sensors. Both work perfectly. I see that the uptime and sensors programs are set for SELinux type=bin_t, which is not the same as what virsh is set for. I think what I need to do is figure out how to ADD (not replace) a new type on the virsh program.
Thanks - Bill Gee
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Change your script to write it to /var/log/virsh.log, then everything should work. I recommend that no priv process ever write to /tmp, /tmp is for users.
logwatch can read log files, so SELinux requires it to have a log label. The default label for anything create in /var/log is var_log_t, which is a log label.
On Sunday, August 24, 2014 06:45:14 Daniel J Walsh wrote:
On 08/23/2014 10:45 AM, Bill Gee wrote:
On Friday, August 22, 2014 08:50:26 Daniel J Walsh wrote:
On 08/21/2014 10:03 AM, Bill Gee wrote:
On Thursday, August 21, 2014 12:00:03 centos-request@centos.org wrote:
Re: [CentOS] SELinux vs. logwatch and virsh From: Daniel J Walsh dwalsh@redhat.com To: CentOS mailing list centos@centos.org
On 08/18/2014 02:13 PM, Bill Gee wrote:
Hi Dan -
"ausearch -m avc -ts recent" produces no output. If I run it as "ausearch -f virsh" then it produces output similar to this. Each day's run of logwatch produces three of these audit log entries. The a1 and a2 values are different for each entry, but everything else is the same.
=============== time->Mon Aug 18 03:21:03 2014 type=SYSCALL msg=audit(1408350063.257:7492): arch=c000003e syscall=21 success=no exit=-13 a0=11ee230 a1=4 a2=7fff722837b0 a3=7fff72283640 items=0 ppid=2815 pid=2816 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=981 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408350063.257:7492): avc: denied { read } for pid=2816 comm="bash" name="virsh" dev="dm-0" ino=135911290 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virsh_exec_t:s0 tclass=file ===============
I thought about using audit2allow as you suggest. The problem is then I don't really know what change is required. What exactly will it do? And is there a guarantee that it will work?
logwatch is executing virsh probably to communicate with libvirt to rotate logs or something. You can look in /etc/logrotate.d for a script with virsh to tell you what the command is trying to do.
Hi Dan -
I know EXACTLY what virsh is being called for. I wrote the script! It has nothing to do with logrotate. I want virsh to tell logwatch what the status is of all virtual machines running on the host. Logwatch will then include that in its daily summary report. SELinux is getting in the way.
Regards - Bill Gee _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Well logrotate is calling the script, and you just need to add the allow rules to allow logrotate to execute the script and communicate with libvirt. Or you need to run the script in a separate cron job to collect the data before the logrotate script runs.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Dan -
Oops, I screwed up the subject line on the last posting. Hopefully corrected with this message.
Comment - I changed my configuration so that virsh is run by a script in cron.daily rather than being called from logwatch. It saves output to a file in /tmp. Logwatch was changed to simply "cat" the file. However, this STILL produces an SELinux violation. I am not any closer to the goal.
Question - How do I add an "allow" rule to SELinux? What exactly is to be allowed and how is SELinux told to do it?
Here is what ausearch finds:
===================== time->Sat Aug 23 03:06:04 2014 type=SYSCALL msg=audit(1408781164.014:1373): arch=c000003e syscall=2 success=no exit=-13 a0=7fffb24e3da6 a1=0 a2=1fffffffffff0000 a3=7fffb24e31d0 items=0 ppid=25741 pid=25742 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=127 comm="cat" exe="/usr/bin/cat" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408781164.014:1373): avc: denied { open } for pid=25742 comm="cat" path="/tmp/libvirt-status" dev="dm-0" ino=768471 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
=====================
Observation - My original idea on this is to have logwatch execute virsh directly. I know it is possible to make that work. The same computer has two other logwatch items that I created. One of them runs uptime and the other runs sensors. Both work perfectly. I see that the uptime and sensors programs are set for SELinux type=bin_t, which is not the same as what virsh is set for. I think what I need to do is figure out how to ADD (not replace) a new type on the virsh program.
Thanks - Bill Gee
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Change your script to write it to /var/log/virsh.log, then everything should work. I recommend that no priv process ever write to /tmp, /tmp is for users.
logwatch can read log files, so SELinux requires it to have a log label. The default label for anything create in /var/log is var_log_t, which is a log label. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I tried both /var/log and /var/cache/logwatch. SELinux denies write permission in both. Here is what ausearch shows:
===================== time->Mon Aug 25 03:20:02 2014 type=SYSCALL msg=audit(1408954802.018:3920): arch=c000003e syscall=59 success=yes exit=0 a0=1704490 a1=1703c60 a2=1704f40 a3=0 items=0 ppid=27898 pid=27900 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=469 comm="virsh" exe="/usr/bin/virsh" subj=system_u:system_r:virsh_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408954802.018:3920): avc: denied { write } for pid=27900 comm="virsh" path="/var/log/libvirt-status" dev="dm-0" ino=203140363 scontext=system_u:system_r:virsh_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file
======================
It only fails when run by cron. If I do "run-parts /etc/cron.daily" from a root login, then everything works as it should.
Bill Gee
On Sunday, August 24, 2014 06:45:14 Daniel J Walsh wrote:
On 08/23/2014 10:45 AM, Bill Gee wrote:
On Friday, August 22, 2014 08:50:26 Daniel J Walsh wrote:
On 08/21/2014 10:03 AM, Bill Gee wrote:
On Thursday, August 21, 2014 12:00:03 centos-request@centos.org wrote:
Re: [CentOS] SELinux vs. logwatch and virsh From: Daniel J Walsh dwalsh@redhat.com To: CentOS mailing list centos@centos.org
On 08/18/2014 02:13 PM, Bill Gee wrote:
Hi Dan -
"ausearch -m avc -ts recent" produces no output. If I run it as "ausearch -f virsh" then it produces output similar to this. Each day's run of logwatch produces three of these audit log entries. The a1 and a2 values are different for each entry, but everything else is the same.
=============== time->Mon Aug 18 03:21:03 2014 type=SYSCALL msg=audit(1408350063.257:7492): arch=c000003e syscall=21 success=no exit=-13 a0=11ee230 a1=4 a2=7fff722837b0 a3=7fff72283640 items=0 ppid=2815 pid=2816 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=981 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408350063.257:7492): avc: denied { read } for pid=2816 comm="bash" name="virsh" dev="dm-0" ino=135911290 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virsh_exec_t:s0 tclass=file ===============
I thought about using audit2allow as you suggest. The problem is then I don't really know what change is required. What exactly will it do? And is there a guarantee that it will work?
logwatch is executing virsh probably to communicate with libvirt to rotate logs or something. You can look in /etc/logrotate.d for a script with virsh to tell you what the command is trying to do.
Hi Dan -
I know EXACTLY what virsh is being called for. I wrote the script! It has nothing to do with logrotate. I want virsh to tell logwatch what the status is of all virtual machines running on the host. Logwatch will then include that in its daily summary report. SELinux is getting in the way.
Regards - Bill Gee _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Well logrotate is calling the script, and you just need to add the allow rules to allow logrotate to execute the script and communicate with libvirt. Or you need to run the script in a separate cron job to collect the data before the logrotate script runs.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Dan -
Oops, I screwed up the subject line on the last posting. Hopefully corrected with this message.
Comment - I changed my configuration so that virsh is run by a script in cron.daily rather than being called from logwatch. It saves output to a file in /tmp. Logwatch was changed to simply "cat" the file. However, this STILL produces an SELinux violation. I am not any closer to the goal.
Question - How do I add an "allow" rule to SELinux? What exactly is to be allowed and how is SELinux told to do it?
Here is what ausearch finds:
===================== time->Sat Aug 23 03:06:04 2014 type=SYSCALL msg=audit(1408781164.014:1373): arch=c000003e syscall=2 success=no exit=-13 a0=7fffb24e3da6 a1=0 a2=1fffffffffff0000 a3=7fffb24e31d0 items=0 ppid=25741 pid=25742 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=127 comm="cat" exe="/usr/bin/cat" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1408781164.014:1373): avc: denied { open } for pid=25742 comm="cat" path="/tmp/libvirt-status" dev="dm-0" ino=768471 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file
=====================
Observation - My original idea on this is to have logwatch execute virsh directly. I know it is possible to make that work. The same computer has two other logwatch items that I created. One of them runs uptime and the other runs sensors. Both work perfectly. I see that the uptime and sensors programs are set for SELinux type=bin_t, which is not the same as what virsh is set for. I think what I need to do is figure out how to ADD (not replace) a new type on the virsh program.
Thanks - Bill Gee
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Change your script to write it to /var/log/virsh.log, then everything should work. I recommend that no priv process ever write to /tmp, /tmp is for users.
logwatch can read log files, so SELinux requires it to have a log label. The default label for anything create in /var/log is var_log_t, which is a log label. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Update:
I recently added a logwatch script to make it run hddtemp. This was done in the same manner as the scripts for virsh. Hddtemp fails with the same kind of message as virsh.
I extracted the audit report using ausearch, submitted it to audit2allow and produced a new policy file. I then imported the new policy file using semodule -i. The new modules does not work. SELinux produces the same "permission denied" message.
Here are text versions of the new modules:
=====================
module libvirt.pol 1.0;
require { type logwatch_t; type virsh_exec_t; class file { read execute }; }
#============= logwatch_t ============== allow logwatch_t virsh_exec_t:file { read execute };
module hddtemp.pol 1.0;
require { type logwatch_t; type fixed_disk_device_t; class blk_file read; }
#============= logwatch_t ============== allow logwatch_t fixed_disk_device_t:blk_file read;
==================
I verified that the new modules are loaded by running semodule --list.
One really curious thing about this is that I have another custom script for logwatch which is working! I set up a script to run "sensors" and capture its output. The sensors script works correctly. The logwatch scripts for both virsh and hddtemp are the same as the sensors script, except for the command they call.
Another curious thing is that it all works perfectly when I "run-parts /etc/cron.daily" from a root login. Why should SELinux regard that as different from when it is run by cron???
Bill Gee
On Thu, Aug 28, 2014 at 07:05:49AM -0500, Bill Gee wrote:
Another curious thing is that it all works perfectly when I "run-parts /etc/cron.daily" from a root login. Why should SELinux regard that as different from when it is run by cron???
Cron runs processes in a different SELinux domain (crond_t I think?) than processes started by the root user, so this is entirely expected behavior.
On Thursday, August 28, 2014 08:24:32 Jonathan Billings wrote:
On Thu, Aug 28, 2014 at 07:05:49AM -0500, Bill Gee wrote:
Another curious thing is that it all works perfectly when I "run-parts /etc/cron.daily" from a root login. Why should SELinux regard that as different from when it is run by cron???
Cron runs processes in a different SELinux domain (crond_t I think?) than processes started by the root user, so this is entirely expected behavior.
But that means that SELinux contexts are NOT stable ... They are NOT the same for all instances of a process. It seems to me that defeats the whole purpose of SELinux.
How does the SELinux inheritance work? How is it related to the user context under which a process runs? As I look at it, I see this chain ...
== Cron run under the crond_t context and chrony user account. It calls logwatch.
==== Logwatch runs under the logwatch_t context and user account of the caller. It calls various binaries such as uptime and hddtemp and virsh.
====== Uptime is bin_t. hddtemp is bin_t. virsh is virsh_exec_t. They all run under the user account of the caller.
If I run-parts from a root login, then the cron service is not involved. The processes all run in the root user account. That does not change their SELinux types, but it sure changes what they can do!
I know this issue is in SELinux somewhere because if I set the system to permissive, then it all works.
Bill Gee
On Thu, Aug 28, 2014 at 08:16:58AM -0500, Bill Gee wrote:
But that means that SELinux contexts are NOT stable ... They are NOT the same for all instances of a process. It seems to me that defeats the whole purpose of SELinux.
I think you're confusing the account the process is running under with the context in which its run. SELinux doesn't really "know" anything about what daemon is running or what user is running them, it just understands that crond is run with a context, and that the SELinux policy allows that process to start certain executables with the appropriate file context, and possibly transitioning to a target domain.
Your root user is unconfined (assuming you haven't done otherwise), so there aren't any restrictions on what it can transition to.
The Cron daemon, when run with SELinux with a process context, can only access files and start processes as defined by the SELinux policy, and can transition to certain domains through defined 'entry points', or executables with a defined file context.
Process transitions are good for cron, because it limits cron to only starting processes properly tagged to enter into that domain, and once the subprocesses have started, they're now confined to what their domain allows. This means that your cron job that rotates httpd's logs can't also start up a sshd on port 22 (for example), even though it is running as root.
On Thursday, August 28, 2014 10:20:06 Jonathan Billings wrote:
On Thu, Aug 28, 2014 at 08:16:58AM -0500, Bill Gee wrote:
But that means that SELinux contexts are NOT stable ... They are NOT the same for all instances of a process. It seems to me that defeats the whole purpose of SELinux.
I think you're confusing the account the process is running under with the context in which its run. SELinux doesn't really "know" anything about what daemon is running or what user is running them, it just understands that crond is run with a context, and that the SELinux policy allows that process to start certain executables with the appropriate file context, and possibly transitioning to a target domain.
Your root user is unconfined (assuming you haven't done otherwise), so there aren't any restrictions on what it can transition to.
The Cron daemon, when run with SELinux with a process context, can only access files and start processes as defined by the SELinux policy, and can transition to certain domains through defined 'entry points', or executables with a defined file context.
Process transitions are good for cron, because it limits cron to only starting processes properly tagged to enter into that domain, and once the subprocesses have started, they're now confined to what their domain allows. This means that your cron job that rotates httpd's logs can't also start up a sshd on port 22 (for example), even though it is running as root.
Hmmm....... OK, let's go back to my original goal. I want logwatch to include the output of "hddtemp /dev/sda" and "virsh --list all" in its daily reports. How is that to be accomplished?
Based on what you said above, I think the way to accomplish it is to add some SELinux entry points to logwatch. Cron is not the problem since it apparently already has an entry point to logwatch.
When I ran "audit2allow" and "semodule -i" commands, was that defining some new entry points?
Is there a way to see the entry points already defined for a given SELinux type?
Thanks - Bill Gee
On Thu, Aug 28, 2014 at 10:29:50AM -0500, Bill Gee wrote:
Hmmm....... OK, let's go back to my original goal. I want logwatch to include the output of "hddtemp /dev/sda" and "virsh --list all" in its daily reports. How is that to be accomplished?
Based on what you said above, I think the way to accomplish it is to add some SELinux entry points to logwatch. Cron is not the problem since it apparently already has an entry point to logwatch.
It doesn't look like the EL6 policy sets a special file context on logwatch (at least, matchpathcon /usr/sbin/logwatch just says it's bin_t) so I think it must be still operating under Cron's context.
When I ran "audit2allow" and "semodule -i" commands, was that defining some new entry points?
Is there a way to see the entry points already defined for a given SELinux type?
If you have the 'selinux-policy-doc' package installed, the man pages for the various services (man crond_selinux, for example) will list the entry points. That's probably the easiest, however, if I look at the 'xm_selinux' man page (virsh has xm_exec_t as the file context) I see the only entry point for the xm_t domain is currently defined is xm_exec_t. This means that the custom policy module will need to allow crond_t to execute xm_exec_t to transition to xm_t (I think). I'm sure someone with SELinux policy experience could comment further.
On Thursday, August 28, 2014 16:07:18 Jonathan Billings wrote:
On Thu, Aug 28, 2014 at 10:29:50AM -0500, Bill Gee wrote:
Hmmm....... OK, let's go back to my original goal. I want logwatch to include the output of "hddtemp /dev/sda" and "virsh --list all" in its daily reports. How is that to be accomplished?
Based on what you said above, I think the way to accomplish it is to add some SELinux entry points to logwatch. Cron is not the problem since it apparently already has an entry point to logwatch.
It doesn't look like the EL6 policy sets a special file context on logwatch (at least, matchpathcon /usr/sbin/logwatch just says it's bin_t) so I think it must be still operating under Cron's context.
When I ran "audit2allow" and "semodule -i" commands, was that defining some new entry points?
Is there a way to see the entry points already defined for a given SELinux type?
If you have the 'selinux-policy-doc' package installed, the man pages for the various services (man crond_selinux, for example) will list the entry points. That's probably the easiest, however, if I look at the 'xm_selinux' man page (virsh has xm_exec_t as the file context) I see the only entry point for the xm_t domain is currently defined is xm_exec_t. This means that the custom policy module will need to allow crond_t to execute xm_exec_t to transition to xm_t (I think). I'm sure someone with SELinux policy experience could comment further.
I think a bit of background got lost. There have been several threads going around on this ... For this I am using CentOS 7.
The SELinux types are set like this:
-rwxr-xr-x. root root system_u:object_r:logwatch_exec_t:s0 /usr/share/logwatch/scripts/logwatch.pl -rwxr-xr-x. root root system_u:object_r:virsh_exec_t:s0 /usr/bin/virsh -rwxr-xr-x. root root system_u:object_r:crond_exec_t:s0 /usr/sbin/crond -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/local/sbin/hddtemp
In CentOS7 there is no package called selinux-policy-doc. I do have man pages with names like crond_selinux. I see entrypoints described in those pages, but I don't have any idea how to use them.
How can I tell SELinux that logwatch_T is permitted to use virsh_t? And for hddtemp, how can I tell SELinux that logwatch_t is permitted to read block devices?
I tried creating modules using audit2allow, but that did not work.
As an experiment, I have made logwatch_t permissive. It works. I now see both hddtemp and virsh output in the logwatch daily report.
semanage permissive -a logwatch_t
Although it works, it seems to me this is not the right way to do it. It is better than setting the whole system to permissive.
Thanks - Bill Gee