Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758800AbcDENH7 (ORCPT ); Tue, 5 Apr 2016 09:07:59 -0400 Received: from 203-219-87-38.static.tpgi.com.au ([203.219.87.38]:43147 "EHLO swtf.swtf.dyndns.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1758779AbcDENH5 (ORCPT ); Tue, 5 Apr 2016 09:07:57 -0400 Subject: Re: [RFC] Create an audit record of USB specific details From: Burn Alting Reply-To: burn@swtf.dyndns.org To: Greg KH Cc: Steve Grubb , linux-audit@redhat.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org In-Reply-To: <20160404215302.GC26580@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> Content-Type: text/plain; charset="UTF-8" Organization: Software Task Force Date: Tue, 05 Apr 2016 23:07:48 +1000 Message-ID: <1459861668.7998.92.camel@swtf.swtf.dyndns.org> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-34.el6) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2887 Lines: 67 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, - 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