[libvirt] [RFC PATCH 0/2] audit cgroup ACL actions in qemu

[Steve Grubb]

On Tuesday, February 15, 2011 09:59:59 pm Eric Blake wrote:
> I'm following up on danpb's patches to add initial audit support to
> qemu actions (see around commit 8dc136b in Oct 2010).  Another useful
> thing to audit is all changes to the device ACL whitelist via the
> cgroup device controller - namely, any time that the qemu cgroup is
> altered to allow or deny access to a (set of) devices.
> 
> I saw an alternate suggestion for collecting the needed audit
> information by using an inotify script outside of libvirt that
> monitors changes to the cgroup file system corresponding to each qemu
> instance; however, this had the drawback that it can only monitor that
> a change is being attempted, but not the actual change being made.  It
> is necessary to use libvirt to provide the audit information, in order
> to have a rich enough set of information to make the audit worthwhile.

Does the cgroup auditing belong in the kernel? Or is there a syscall that would catch 
this?

> I believe this patch series catches all instances where libvirt
> modifies the whitelist for a qemu instance, but I didn't do anything
> for when libvirt first creates a separate cgroup device whitelist as
> part of starting a new guest.  Also, I'm not sure if the amount of
> information passed to the audit is adequate, or if it needs tweaking.

We would need to see some sample events. This patch should also be reviewed on the 
rhel6-cc-external-list so that Stephan can weigh in  on whether you have everything 
he's expecting.

> Also, libvirt blindly passes a long list of paths through the
> low-level util/cgroup.c functions, including non-devices where it
> ignores the EINVAL failure later.  But this could pollute the audit
> log with entries corresponding to cases where altering the actual
> cgroup was never even attempted.

The audit event log needs to be accurate. You should never put events in there that 
aren't true.

> Should I tweak things to only do an audit when an actual cgroup change was attempted
> (perhaps by modifying util/cgroup.c to return 0 on success, 1 on skip, and -errno on
> failure, rather than the current -EINVAL on skip)?

Probably. But also be careful about skipping too many things because there may be 
things with -EPERM/EACCES that we might want. I think I'd discuss this on the rhel6-cc 
list for clarification.

-Steve