On Tue, Apr 05, 2016 at 03:38:34PM -0400, Steve Grubb wrote: > On Tuesday, April 05, 2016 07:02:48 PM Oliver Neukum wrote: > > On Tue, 2016-04-05 at 18:40 +1000, Wade Mealing wrote: > > > Consider the following scenario. Currently we have device drivers > > > that emit text via a printk request which is eventually picked up by > > > syslog like implementation (not the audit subsystem). > > > > We also have UEVENTs. The crucial question is why udevd feeding > > back events to the audit subsystem is inferior to the kernel > > itself generating audit events. > > If this was going to be done in user space, then we are talking about auditd > growing the ability to monitor another netlink socket for events. The question > that decides if this is feasible is whether or not UEVENTS are protected from > loss if several occur in a short time before auditd can get around to reading > them. udevd should queue up your events that you subscribe to just fine. Test it out if you want to, it should be pretty easy. > The other issue that I'm curious about is if adding hardware can fail. Sure it can, plug in a "broken" USB device and watch it not enumerate properly :) > Do the events coming out by UEVENTS have any sense of pass or fail? Or > are they all implicitly successful? They only happen when a device is successfully added to the kernel. > And then we get to the issue of whether or not UEVENTS can be filtered. If so, > then we will also need to add auditing around the configuration of the filters > to see if anything is impacting the audit trail. You can filter in userspace, that's what udevd provides for you today. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
