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: <1459861668.7998.92.camel@swtf.swtf.dyndns.org>
Date:	Tue, 05 Apr 2016 23:07:48 +1000
From:	Burn Alting <burn@...f.dyndns.org>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Steve Grubb <sgrubb@...hat.com>, linux-audit@...hat.com,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC] Create an audit record of USB specific details

On Mon, 2016-04-04 at 14:53 -0700, Greg KH wrote:
> On Mon, Apr 04, 2016 at 02:48:43PM -0700, Greg KH wrote:
> > On Mon, Apr 04, 2016 at 05:33:10PM -0400, Steve Grubb wrote:
> > > On Monday, April 04, 2016 05:56:26 AM Greg KH wrote:
> > > > On Mon, Apr 04, 2016 at 12:02:42AM -0400, wmealing wrote:
> > > > > From: Wade Mealing <wmealing@...hat.com>
> > > > > 
> > > > > Gday,
> > > > > 
> > > > > I'm looking to create an audit trail for when devices are added or removed
> > > > > from the system.
> > > > 
> > > > Then please do it in userspace, as I suggested before, that way you
> > > > catch all types of devices, not just USB ones.
> > > > 
> > > > Also I don't think you realize that USB interfaces are what are bound to
> > > > drivers, not USB devices, so that is going to mess with any attempted
> > > > audit trails here.  How are you going to distinguish between the 5
> > > > different devices that just got plugged in that all have 0000/0000 as
> > > > vid/pid for them because they are "cheap" devices from China, yet do
> > > > totally different things because they are different _types_ of devices?
> > > 
> > > This sounds like vid/pid should be captured in the event.
> > 
> > The code did that, the point is, vid/pid means nothing in the real
> > world.  So why are you going to audit anything based on it? :)
> 
> Oh wait, it's worse, it is logging strings, which are even more
> unreliable than vid/pid values.  It's pretty obvious this has not been
> tested on any large batch of real-world devices, or thought through as
> to why any of this is even needed at all.
> 
> So why is this being added?  Who needs/wants this?  What are their
> requirements here? 

As a consumer of auditd events for security purposes, the questions I
would like answered via the sort of audit framework Wade is putting
together are

- when was a (possible) removable media device plugged into a system and
what were the device details - perhaps my corporation has a policy on
what devices are 'official' and hence one looks for alternatives,
and/or,
- was it there at boot ? (in case someone adds and removes such devices
when powered off), and eventually
- has an open for write (or other system calls) occurred on designated
removable media? (i.e. what may have been written to removable media -
cooked or raw) - Yes, this infers a baseline of what's connected or an
efficient means of working out if a device is 'removable' at system call
time.

In essence, I need to know if and how removable media is being used on
my systems. The definition of 'removable' is challenging, but my idea
would be for one to be able to define it via the auditd interface.


>  From what I recall, the author is just messing
> around with the USB subsystem and audit as something fun to do, which is
> great, but don't expect it to be mergable :)
> 
> thanks,
> 
> greg k-h
> 

Regards
Burn Alting