[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1459895969.7998.139.camel@swtf.swtf.dyndns.org>
Date: Wed, 06 Apr 2016 08:39:29 +1000
From: Burn Alting <burn@...f.dyndns.org>
To: "Boyce, Kevin P (AS)" <Kevin.Boyce@....com>
Cc: Greg KH <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-audit@...hat.com" <linux-audit@...hat.com>
Subject: RE: EXT :Re: [RFC] Create an audit record of USB specific details
On Tue, 2016-04-05 at 14:42 +0000, Boyce, Kevin P (AS) wrote:
> Burn,
>
> > 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
>
> And even when you try to figure this out for a CD it is next to impossible to know what is written. If I remember correctly when running strace on wodim you don't ever see the write() calls on the filenames. And instead, what if someone creates an iso image and burns that to a DVD. You really have no way of knowing what is on that disc. When the burn process is complete, the disc usually gets ejected, so the audit subsystem would never even get a chance to evaluate the filesystem that was written to optical media.
Two issues here.
1. If you need to know what has been transferred to removable media,
then use appropriate DLP (data loss prevention) capability that, not
only provides management on who/what can be involved in transfers, but
can also keep shadow copies of data transferred.
2. If no DLP tools are available, then we need to make use of audit but
we do not rely on a single event in isolation. Reviewing events both
before and after a removable media event, along with events from other
services (web servers, applications) allows one to build a 'balance of
probabilities' picture of what has occurred. (The balance of
probabilities is improved with more information of value and it's
integrity).
Apologies for going off topic on theses lists, but I am hoping this
background to our requirements will aid in any further discussion
regarding solutions people such as Wade are investigating. If there is a
desire to continue, it's probably best we move such discussions to audit
specific lists or dedicated forums and return when required with
kernel/usb specific issues.
Regards
Burn
Powered by blists - more mailing lists