
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