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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list