reactive audit proposal

Hello, I wanted to run this by the crowd to see what people's reaction might be. The audit system sometimes needs to have rules applied when something happens. For example, if someone plugs in a USB flash drive, the system creates the device in /dev and then automatically mounts it under some circumstances. I would propose 2 new additions to the audit rule syntax: on-mount and on-login.These rules would be in a separate file from the main audit rules. When a file system is mounted, /proc/mounts changes and the mount table can be scanned to see if something new is there. In this way we can reliably detect newly mounted filesystems. We can then match against a specifier to see if this is a file system in which we want to apply new rules. If so, we send the new rules to the kernel. When the device is unmounted, the kernel drops all watches on that file system. So, we only need to worry about when a device is mounted. This works good for anything that gets mounted. But it is also possible for a USB flash drive to be accessed as a block device, such as the dd utility. If we had to detect device discovery, there is a netlink group, NETLINK_KOBJECT_UEVENT which we could monitor for events. The only thing is that we could only detect open/read/write/close/ioctl/lseek. And we probably do not want to monitor anything except block devices. It may also be possible to poll /sys/block to watch for changes. This might be easier as the names are more friendly. This would take some research to see if its even possible. The rule syntax could look something like: on=mount mount=/run/user/1000 : -a exit,always ... on=device device=/dev/sdd : -a exit,always ... The on-login event would simply watch the audit trail for any AUDIT_LOGIN events. That event can be parsed to get the new auid. If the auid matches any rules, then it will load them into the kernel. To remove the rules, we could watch for the AUDIT_USER_END event. The only issue is that we would need to track how many sessions the user has open and remove the rules only when the last session closes out. The rules for this might look something like this: on=login auid=1000 : -a exit,always ... The question is whether or not this should be done as part of the audit daemon or as a plugin for the audit daemon. One advantage of doing this as a plugin is that it will keep the audit daemon focused on getting events and distributing them. Any programming mistake in the plugin will crash it and not the daemon. The tradeoff is that it will get the event slightly after auditd sees it. This only matters for the on-login functionality. The device and mount events come from an entirely different source. And I'm sure that in every case, the program will react faster than a user possibily can winning the race evry time. Thoughts? -Steve