Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753235AbcDEOkg (ORCPT ); Tue, 5 Apr 2016 10:40:36 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:41550 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752028AbcDEOke (ORCPT ); Tue, 5 Apr 2016 10:40:34 -0400 Date: Tue, 5 Apr 2016 10:40:33 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Wade Mealing cc: =?UTF-8?Q?Bj=C3=B8rn_Mork?= , Oliver Neukum , , , linux-usb Subject: Re: [RFC] Create an audit record of USB specific details In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2600 Lines: 53 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