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.
> Regarding your general question ... It seems to me that logwatch can be used
> to provide feedback on operational status of almost anything on the system.
> If you go beyond the typical reading of log files, then that often requires
> running some script or utility program or something. Anytime that is done, I
> think this kind of problem will appear.
Right, but I am looking for packages that drop logrotate scripts rather
then just thowing in the tile and saying lograte
is an unconfined domain. If a package ships a script that SELinux will
break, I want to know what is the risk of a
hacked logrotate executable causing havoc on a system. Potentially I
can add a boolean to policy to allow the access
but deny it by default.
> Much of what logwatch does is running files through "cat". That process runs
> as "bin_t" which must be a general type. I wonder what would happen if I
> changed virsh to the same type.
You could try that, I think you will end up with other AVC's concerning
logratote talking to libvirt.
> For what it is worth, I have another computer running CentOS 6.5 and
> VirtualBox. The VBoxManage program must run as the same user which is running
> the virtual machines, which frustrates me to no end. I finally figured out a
> way to work around it by setting up a user cron job under that user. It saves
> the output to a text file. The logwatch script then comes along and reads that
> file into its output. It works, but it is not ideal. There are obvious
> problems with synchronization, plus if a computer is running VMs under
> multiple user accounts, then multiple user cron jobs are needed.
>
> Thanks - Bill Gee
>
>
> =============================
>> _______________________________________________
>> CentOS mailing list
>> CentOS@xxxxxxxxxx
>> http://lists.centos.org/mailman/listinfo/centos
> What AVC messages are you seeing?
>
> ausearch -m avc -ts recent.
> I would put the machine in permissive mode, run your tests and then add
> the allow rules using
>
> audit2allow -M mylogwatch
>
>
>
>
>
> Message: 8
> Date: Fri, 15 Aug 2014 11:22:40 -0400
> From: Daniel J Walsh <dwalsh@xxxxxxxxxx>
> Subject: Re: SELinux vs. logwatch and virsh
> To: CentOS mailing list <centos@xxxxxxxxxx>
> Message-ID: <53EE25C0.3040404@xxxxxxxxxx>
> Content-Type: text/plain; charset=windows-1252
>
>
> On 08/14/2014 11:02 AM, Bill Gee wrote:
>> Hello everyone -
>>
>> I am stumped ... Does anyone have suggestions on how to proceed? Is there
> a way
>> to get what I want?
>>
>> The environment: CentOS 7.0 with latest patches.
>>
>> The goal: I want logwatch to include a report on the status of kvm virtual
> computers.
>> The problem: When run from anacron, SELinux denies permission for the virsh
> utility.
>> Here is a portion of the logwatch output:
>>
>> --------------------- KVM libvirt status report Begin
> ------------------------
>> Date Range: yesterday
>> /etc/logwatch/scripts/services/libvirt: line 15: /usr/bin/virsh: Permission
> denied
>>
>> ---------------------- KVM libvirt status report End
> -------------------------
>> If I "run-parts /etc/cron.daily" from a root console, it all works. Same
> if I run "logwatch"
>> from a root console.
>>
>> I set SELinux to permissive and that allows virsh to run. Therefore I know
> it is
>> something to do with SELinux.
>>
>> The logwatch script is:
>>
>> #Lots of comments
>> /usr/bin/virsh list --all
>>
>> I see the selinux security context of virsh is
>>
>> system_u:object_r:virsh_exec_t:s0
>>
>> while logwatch.pl runs as
>>
>> system_u:object_r:logwatch_exec_t:s0
>>
>> As I understand it, selinux does not permit having multiple type settings
> for a file. Any
>> file can have exactly one type setting.
>>
>> I ran this command hoping it would add another type to the virsh program.
>>
>> semanage fcontext -a -t logwatch_exec_t /usr/bin/virsh
>>
>> semanage fcontext --list /usr/bin/virsh | grep virsh
>> /usr/bin/virsh all files
>> system_u:object_r:logwatch_exec_t:s0
>> /usr/bin/virsh regular file
> system_u:object_r:virsh_exec_t:s0
>> /usr/sbin/xl regular file
> system_u:object_r:virsh_exec_t:s0
>> /usr/sbin/xm regular file
> system_u:object_r:virsh_exec_t:s0
>> Semanage did add the new type, but that did not fix the problem. Virsh still
> gets
>> "permission denied" when logwatch tries to run it.
>>
>> Thanks - Bill Gee
>> _______________________________________________
>> CentOS mailing list
>> CentOS@xxxxxxxxxx
>> http://lists.centos.org/mailman/listinfo/centos
> BTW if you think this is something we should do in general in such a way
> as logwatch can only look at the content in Read Only mode, then we
> might want it to become default.
>
>
>
>
> ------------------------------
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
