linux-kernel - Re: [RFC] Create an audit record of USB specific details

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Apr 2016 10:40:33 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Wade Mealing <wmealing@...hat.com>
cc:	Bjørn Mork <bjorn@...k.no>,
	Oliver Neukum <oneukum@...e.com>, <linux-audit@...hat.com>,
	<linux-kernel@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>
Subject: Re: [RFC] Create an audit record of USB specific details

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