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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
