RE: EXT :Re: [RFC] Create an audit record of USB specific details

["Boyce, Kevin P (AS)" <Kevin.Boyce@ngc.com>]

Wade,

Wouldn't this imply that every time the system is booted and the PCI bus for example is enumerated and all of the devices are created that all of those 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 system?  

Couldn't you audit a directory under /proc/usb?
Correct me if I am wrong, but doesn't audititing of the syscall mknod create 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ørn Mork
Cc: Oliver Neukum; linux-kernel@vger.kernel.org; linux-usb; linux-audit@redhat.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 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?

Thanks,

Wade Mealing

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit