Subject: Re: [RFC] Create an audit record of USB specific details
From: Burn Alting <burn@swtf.dyndns.org>
Reply-To: burn@swtf.dyndns.org
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Steve Grubb <sgrubb@redhat.com>, linux-audit@redhat.com,
        linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <20160405134427.GB31313@kroah.com>
References: <1459742562-22803-1-git-send-email-wmail@redhat.com>
	 <20160404125626.GB6197@kroah.com> <8028201.ZHuhRfiKWv@x2>
	 <20160404214843.GA26580@kroah.com> <20160404215302.GC26580@kroah.com>
	 <1459861668.7998.92.camel@swtf.swtf.dyndns.org>
	 <20160405134427.GB31313@kroah.com>
Content-Type: text/plain; charset="UTF-8"
Organization: Software Task Force
Date: Wed, 06 Apr 2016 00:08:24 +1000
Message-ID: <1459865304.7998.102.camel@swtf.swtf.dyndns.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3825
Lines: 87

On Tue, 2016-04-05 at 09:44 -0400, Greg KH wrote:
> On Tue, Apr 05, 2016 at 11:07:48PM +1000, Burn Alting wrote:
> > 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@redhat.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,
> 
> How do you determine if a USB device is "official" or not?  What
> attribute(s) are you going to care about that can't be trivially
> spoofed?

One typically can't defeat the knowledgeable and determined person, but
this doesn't mean you don't try. In the windows world, most DLP
capabilities make use of Manufacturer/Model/Serial in combination with
user and system to determine/record access. In the case of Linux audit,
we would be closing the gate after the horse has bolted, but at least we
know it has occurred.

> 
> > - was it there at boot ? (in case someone adds and removes such devices
> > when powered off), and eventually
> 
> What if you booted off of it?

Which means audit could be defeated anyway since one controls the OS,
but again one still needs to try.

> 
> > - 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.
> 
> Yes, determining "removable" is non-trivial, good luck with that :)

I was hoping for a configurable table that could be pre-seeded and
either managed via the audit interface (add/delete/masked). Pre-seed
with well known devices such as cd/dvd, usb mass storage, scsi devices
with the RMB bit set, etc and go from there. We need to start
somewhere ... 


> 
> thanks,
> 
> greg k-h