RE: EXT :Re: [RFC] Create an audit record of USB specific details

In all of this discussion about auditing insertion and removal of usb devices, I would mention that you'd want a complete solution, not just USB. If you are trying to prevent people from stealing data or know what data they stole (as in the case of Eric Snowden and Brad Manning) I would think you would be concerned with Firewire, CDROM/DVD/Blu Ray, Tape, printer, and other devices one could use for espionage. Perhaps you would also want to document in the audit system what file operations were performed on the file system of the rogue device. These become very difficult tid bits of information to produce, especially considering all of the ways one could use to write to a device.

Kevin -----Original Message----- From: linux-audit-bounces(a)redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Burn Alting Sent: Tuesday, April 05, 2016 10:08 AM To: Greg KH Cc: linux-kernel(a)vger.kernel.org; linux-usb(a)vger.kernel.org; linux-audit(a)redhat.com Subject: EXT :Re: [RFC] Create an audit record of USB specific details 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(a)redhat.com&gt; > > > > > > > > > > > > > > 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