On Tue, 2016-04-05 at 14:20 +0000, Boyce, Kevin P (AS) wrote: > 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. >
Hence my final comment below about well known devices and the desire monitor open/openat/etc for write system calls on 'deemed removable media' ie one day we could set up auditctl -F arch=b64 -a always,exit -S open -F a1&3 -F dev=removable -k RMopen Burn > Kevin > > -----Original Message----- > From: linux-audit-boun...@redhat.com [mailto:linux-audit-boun...@redhat.com] > On Behalf Of Burn Alting > Sent: Tuesday, April 05, 2016 10:08 AM > To: Greg KH > Cc: linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org; > linux-au...@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 <wmeal...@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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
