Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758990AbcDENoa (ORCPT ); Tue, 5 Apr 2016 09:44:30 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48859 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755943AbcDENo3 (ORCPT ); Tue, 5 Apr 2016 09:44:29 -0400 Date: Tue, 5 Apr 2016 09:44:27 -0400 From: Greg KH To: Burn Alting Cc: Steve Grubb , linux-audit@redhat.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC] Create an audit record of USB specific details Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1459861668.7998.92.camel@swtf.swtf.dyndns.org> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2875 Lines: 65 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 > > > > > > > > > > > > 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? > - 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? > - 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 :) thanks, greg k-h