From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Boyce, Kevin P (AS)" Subject: RE: EXT :Re: [RFC] Create an audit record of USB specific details Date: Tue, 5 Apr 2016 11:49:14 +0000 Message-ID: <889498a2eca043d5af1fe23ffb574284@XCGVAG30.northgrum.com> References: <1459742562-22803-1-git-send-email-wmail@redhat.com> <1459752519.24025.5.camel@suse.com> <87bn5pzuh1.fsf@nemi.mork.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Wade Mealing , =?iso-8859-1?Q?Bj=F8rn_Mork?= Cc: Oliver Neukum , "linux-kernel@vger.kernel.org" , linux-usb , "linux-audit@redhat.com" List-Id: linux-audit@redhat.com Wade, Wouldn't this imply that every time the system is booted and the PCI bus fo= r example is enumerated and all of the devices are created that all of thos= e activities generate audit events? That sounds less than desiriable. Does this imply that the audit subsystem= should maintain a "baseline" of hardware that is always present on the sys= tem? = Couldn't you audit a directory under /proc/usb? Correct me if I am wrong, but doesn't audititing of the syscall mknod creat= e an event when devices are "added" to the system? Kevin -----Original Message----- From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com= ] On Behalf Of Wade Mealing Sent: Tuesday, April 05, 2016 4:40 AM To: Bj=F8rn Mork Cc: Oliver Neukum; linux-kernel@vger.kernel.org; linux-usb; linux-audit@red= hat.com Subject: EXT :Re: [RFC] Create an audit record of USB specific details I'm reframing my use case as follows to try and better explain the situatio= n I am trying to track. It might seem that I am duplicating existing functionality, rather I am try= ing to augment functionality that seems to be unavailable.Replication of ex= isting functionality is not my intention. Consider the following scenario. Currently we have device drivers that emi= t text via a printk request which is eventually picked up by syslog like im= plementation (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 audit= ctl at some point in the future. Specifically I am trying to create a well formed audit trail when devices a= re added or removed from the system by the userspace audit tools. The impl= ementation 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 cas= e the class is unaware it is being decorated yet we can monitor what is hap= pening in that class without polluting the class code with messy log or tra= ce information. I don't see either kernel or user-space applications create add or remove e= vents in the audit subsystem. I understand that some events are placed int= o uevents (To be intercepted by udevd), while this also exports the same in= formation 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 faciliti= es for auditing and not duplicating efforts, it seems that the specific cas= e I am trying to track isn't covered. Maybe I missed it be can you indicat= e where device add/remove audit (not log messages) are being generated/impl= emented in the kernel or userspace for the scenario I described? Thanks, Wade Mealing -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit