Re: [RFC] Virtual machine related events support

[Marcelo Cerri <mhcerri@linux.vnet.ibm.com>]

Hi Steve,

Thanks for your feedback.

I'm already coding the auvirt tool and I'd like to add command line 
options similar to "--start" and "--end" from ausearch.

Looking into ausearch code I found two functions (ausearch_time_end and 
ausearch_time_start) that already parse date and time informed and 
support some interesting options as "now", "today", "week-ago" and etc.

Do you think there would be a problem in use these functions in auvirt?

Regards,
Marcelo

On 12/03/2011 11:59 AM, Steve Grubb wrote:
> On Friday, November 11, 2011 05:26:20 PM Marcelo Cerri wrote:
>> Hi,
>>
>> We are working on a project in which we need to get some events from
>> audit log related to virtual machine events and filter these events per
>> guests. Currently, the audit tools doesn't support this kind of search.
>> However we are willing to implement the necessary features to support it
>> and we'd like to receive some feedback from audit stakeholders on our
>> proposal.
>>
>> Most of these records are generated by libvirt, but some of them are
>> generated by SELinux (as AVC denials). To get events generated by
>> libvirt, we'd like to search through audit records using the both "uuid"
>> and "vm" fields.
>> The following records are examples of both types of records that we
>> intend to filter:
>>
>> type=VIRT_RESOURCE msg=audit(1319602467.134:33): user pid=14103 uid=0
>> auid=4294967295 ses=4294967295 msg='resrc=disk reason=start
>> vm="CentOS-Guest" uuid=41ffecd5-037e-0059-b074-ab2bf354fd0a old-disk="?"
>> new-disk="/var/lib/libvirt/images/CentOS-Guest.img":
>> exe="/usr/sbin/libvirtd" (hostname=?, addr=?, terminal=? res=success)'
>> type=AVC msg=audit(1318529059.690:801): avc:  denied  { read } for
>> pid=31199 comm="qemu-kvm" name="RHEL6.img" dev=dm-0 ino=524635
>> scontext=system_u:system_r:svirt_t:s0:c99,c999
>> tcontext=system_u:object_r:svirt_image_t:s0:c390,c835 tclass=file
>>
>> While "vm" field contains the domain name and it's a more user friendly
>> identifier, it's intended to be a unique only within the scope of a
>> single host. On the other hand, "uuid" field is intended to be a global
>> identifier.
>>
>> We'd like to create a stand-alone tool, similar to aulast, to filter
>> this kind of events and that could be part of audit's tools. It'd be
>> able to list VM specific events, and filter these events by UUID or VM
>> name if needed. We are intended to support the following usage/options
>> (any suggestions are welcome):
>>
>>      Usage: auvirt [ options ] [ uuid | vm-name ]
>>
>>      Options:
>>
>>           --summary(default)
>>               Write a formatted output containing summarized information as
>>               considered time period, total number of VM specific events,
>> total
>>               number of events by type (start, stop, resource change) and
>> total
>>               number of AVC events.
>>
>>           --raw
>>               Write records related to guests as shown in audit.log. The
>>               output may contain the following record types: VIRT_CONTROL,
>>               VIRT_RESOURCE, VIRT_MACHINE_ID and AVC.
>>
>>           -f file, --stdin
>>               Same as aulast.
>>
>> We intend to correlate AVC denial events to guests through the security
>> label used by a guest in a specific period.
> This sounds fine.
>
>
>> Another proposal would be change ausearch to support two new search
>> options:
>>
>>    -uu, --uuid vm-uuid
>>        Search for an event with the given UUID.
>>
>>    -vm, --vm-name vm-name
>>        Search for an event with the given virtual machine name.
> This sounds fine.
>
>
>> However, these fields are defined by libvirt and it may be a good idea
>> to add to libaudit a new "audit_log_*" function to enforce a standard
>> message format for VM related events that could be used by other
>> virtualization tools.
> This also sounds fine.
>
> I was also considering making a very basic report in aureport but as you can see from
> aulast, sometimes a special dedicated report is better for different kinds of uses.
>
> -Steve
>