On Mon, Mar 14, 2016 at 12:01:11AM -0400, Wade Mealing wrote: > > >> 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. No, I mean just call usb_register_notify(), it's all there for you today... > >> 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. 1 and 2 can be done from userspace, please do so, no need to mess with the kernel at all. And why would you need to audit anything before your initramfs started? That's under your control, not anyone elses. 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
