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>
> > > > > >
> > > > > > 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