On Tue, 5 Apr 2016, Wade Mealing wrote: > I'm reframing my use case as follows to try and better explain the > situation I am trying to track. > > It might seem that I am duplicating existing functionality, rather I > am trying to augment functionality that seems to be > unavailable.Replication of existing functionality is not my intention. > > 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). > > The goal of these message is to let a system administrator see in the > audit logs, that a device has been plugged in and the basic details > about this. Having this only in userspace means that (and Greg > alludes to this ) that this will be for human eyes only and not be > machine usable in the kernels. Without it being in kernel, it can't > be extended for manipulation by auditctl at some point in the future. > > Specifically I am trying to create a well formed audit trail when > devices are added or removed from the system by the userspace audit > tools. The implementation at the moment does not do any filtering, > but rather creates the raw audit events. > > In some ways this is similar to a decorated class in say java. In > this case the class is unaware it is being decorated yet we can > monitor what is happening in that class without polluting the class > code with messy log or trace information. > > I don't see either kernel or user-space applications create add or > remove events in the audit subsystem. I understand that some events > are placed into uevents (To be intercepted by udevd), while this also > exports the same information it is not in the audit subsystem in > kernel. > > > I think the generic layer implementation is already there. The proposed > > USB specific solution adds nothing, as pointed out by Greg the last time > > this was discussed. > > I agree it would be ideal to use existing userspace or kernelspace > facilities for auditing and not duplicating efforts, it seems that the > specific case I am trying to track isn't covered. Maybe I missed it > be can you indicate where device add/remove audit (not log messages) > are being generated/implemented in the kernel or userspace for the > scenario I described? If you want a place in the kernel to add audit records for all devices added to or removed from the system, the right place to do it is in drivers/base/core.c, the device_add() and device_del() routines. That's where the ADD and REMOVE uevents are created. Alan Stern -- 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
