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]

Message-ID: <CALJHwhR5FQaa6v=ZPyLRZ8L+OrucXqEiwe6QE43HybM2keErYg@mail.gmail.com>
Date:	Tue, 5 Apr 2016 18:40:09 +1000
From:	Wade Mealing <wmealing@...hat.com>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	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

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