>> I'd like to extend the device audit subsystem to log some of the >> device additions/removals to the kernel > Why? What are you going to do with this information? What is it going > to be used for, are you going to act on it? Me personally, no I'm not going to act on it. But it can be useful for building up a profile on the events leading up to a system event such as a compromise or perhaps at some point acting on it as part of the audit project. Custom IDS systems can also respond to linux kernel events as you probably already know. >> Why not have your audit code just register with the USB core to get the >> data this way? No need to modify any USB code at all. Do you mean like an external file/function set, and just dig into the usb structs when required ? Sure I can do that.. I thought having it in the relevant subsystem code would be a cleaner place and easier to maintain if/when changes were made. >> But again, what are you going to do with this information that userspace >> doesn't already have (hint, you are keeping track of all uevents, >> right?) So the game plan kinda was like this: 1) Extract information about the kernel about attach/detach events (not just USB, but PCIE, firewire, bus, hubs, etc,). 2) Find the /dev/ nodes made (as far as I can tell I can't find this easily in the kernel, this part will need to be done via systemd (uevents). 3a) (Optionally for disks) auditctl can already log the mount/umount command, so the whole process can be audited from that point. 3b) Other device open/close/read write will fall under normal audit rules. Yes, ideally keeping audit logs of both would be the step forward. I was thinking that the udev part of systemd was the ideal place to log those events also. If (1) can entirely be done in systemd/udev with kobjects that is cool, I just didn't think it could, especially for every subsystem type, and especially before systemd starts. Thanks, Wade Mealing -- 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
