One way is to watch for the main folder where /dev/sr0 is mounted. That way everything under that is watched. If an ISO is burned then we cannot know what is inside that ISO. An alternative is to watch access to known sensitive files on the machine (whose cd burner you want to watch). and known burning commands. That way you know who is accessing sensitive content. If the same login session generates events for these files and programs they might be burning sensitive files. On Tue, Apr 22, 2014 at 3:14 PM, Boyce, Kevin P. (AS) <kevin.boyce(a)ngc.com <mailto:kevin.boyce@ngc.com>> wrote: Does anyone know if it is possible to audit what filenames users are burning to optical media? I suppose I can put a watch on the /dev/sr0 device for write events, but this does not give me any idea what was written to the disc. I suppose I could also set an execve watch all burner programs, eg. /usr/bin/k3b /usr/bin/brasero /usr/bin/cdrecord /usr/bin/cdrdao /usr/bin/dvdrecord, to know if someone opened the burning interface; but how could I tell what it was they were writing? Any suggestions are welcome. Kevin -- Linux-audit mailing list Linux-audit(a)redhat.com <mailto:Linux-audit@redhat.com> https://www.redhat.com/mailman/listinfo/linux-audit -- Please Donate to www.wikipedia.org <http://www.wikipedia.org>

Even if there is a file system it may not be mounted on a known a folder. But monitoring access of sensitive content and execution of burning programs can provide clues. You can use audit dispatcher to react to audit events.... When u get a MOUNT event you can see where sr0 is mounted and start a new watch for that path. If you are not writing an ISO I think it has to be mounted. On Tuesday, April 22, 2014, Boyce, Kevin P. (AS) <kevin.boyce(a)ngc.com <mailto:kevin.boyce@ngc.com>> wrote: Hmm. That is an interesting thought, but I would think there is no filesystem that would be able to be mounted until the user has written something to the disc first. In other words I don't believe blank media gets mounted as part of the burning process (at least not in my experience anyways--maybe I'd need to turn some feature on for that?). Kevin On 04/22/2014 03:32 PM, Satish Chandra Kilaru wrote: > One way is to watch for the main folder where /dev/sr0 is > mounted. That way everything under that is watched. > If an ISO is burned then we cannot know what is inside that ISO. > > An alternative is to watch access to known sensitive files on the > machine (whose cd burner you want to watch). and known burning > commands. That way you know who is accessing sensitive content. > If the same login session generates events for these files and > programs they might be burning sensitive files. > > > On Tue, Apr 22, 2014 at 3:14 PM, Boyce, Kevin P. (AS) > <kevin.boyce(a)ngc.com > <javascript:_e(%7B%7D,'cvml','kevin.boyce@ngc.com');>> wrote: > > Does anyone know if it is possible to audit what filenames > users are burning to optical media? > > I suppose I can put a watch on the /dev/sr0 device for write > events, but this does not give me any idea what was written > to the disc. I suppose I could also set an execve watch all > burner programs, eg. /usr/bin/k3b /usr/bin/brasero > /usr/bin/cdrecord /usr/bin/cdrdao /usr/bin/dvdrecord, to > know if someone opened the burning interface; but how could I > tell what it was they were writing? > > Any suggestions are welcome. > > Kevin > > -- > Linux-audit mailing list > Linux-audit(a)redhat.com > <javascript:_e(%7B%7D,'cvml','Linux-audit@redhat.com');> > https://www.redhat.com/mailman/listinfo/linux-audit > > > > > -- > Please Donate to www.wikipedia.org <http://www.wikipedia.org> -- Please Donate to www.wikipedia.org <http://www.wikipedia.org>

Does the audit subsystem have the ability to dynamically create new auditing rules using another event as the trigger?

On Tuesday, April 22, 2014 04:06:05 PM Steve Grubb wrote: > On Tuesday, April 22, 2014 03:44:45 PM Boyce, Kevin P. wrote: > > Does the audit subsystem have the ability to dynamically create new > > auditing rules using another event as the trigger? > > There was a patch for a reactive plugin sent to the list a number of years > ago. The patch was too big and bounced, but I was cc'ed and have a copy. I > have not had the time to review it to see if its maintainable, supportable, > and exactly what I'd want. It's actually pretty well documented. I could > probably make it available off my people page since its too large for the > mail list. http://people.redhat.com/sgrubb/audit/reactive/ I have not reviewed the patch. I don't know if it still compiles or needs changes. I am very interested in the topic of being able to load more rules to watch something closer when certain things occur. If you look at the pdf, one of the use cases it assists in is auditing files on removable media. I would like to hear feedback on this patch to see what others think. -Steve -- Linux-audit mailing list Linux-audit(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit

On Wednesday, April 23, 2014 08:00:47 AM Burn Alting wrote: > Steve, > > The main challenge for this solution is the definition of all audit > events that imply removable media has been attached. These are all hotplug events. Udev should see them all.

> Juraj's example of monitoring for mount system calls covers the edge case of > copying to/from mounted devices (given you also identify removable devices > mounted as opposed to say network mounts), but it would not cover the > edge case of say dd'ing to a raw umounted device. > > By the way, linking to > http://people.redhat.com/sgrubb/audit/reactive/reactive-audit-thesis.pdf > results in Fixed. Thanks. -Steve > On Tue, 2014-04-22 at 16:39 -0400, Steve Grubb wrote: >> On Tuesday, April 22, 2014 04:06:05 PM Steve Grubb wrote: >>> On Tuesday, April 22, 2014 03:44:45 PM Boyce, Kevin P. wrote: >>>> Does the audit subsystem have the ability to dynamically create new >>>> auditing rules using another event as the trigger? >>> >>> There was a patch for a reactive plugin sent to the list a number of >>> years >>> ago. The patch was too big and bounced, but I was cc'ed and have a copy. >>> I >>> have not had the time to review it to see if its maintainable, >>> supportable, >>> and exactly what I'd want. It's actually pretty well documented. I could >>> probably make it available off my people page since its too large for >>> the >>> mail list. >> >> http://people.redhat.com/sgrubb/audit/reactive/ >> >> I have not reviewed the patch. I don't know if it still compiles or needs >> changes. I am very interested in the topic of being able to load more >> rules to watch something closer when certain things occur. If you look at >> the pdf, one of the use cases it assists in is auditing files on >> removable media. >> >> I would like to hear feedback on this patch to see what others think. >> >> -Steve >> >> -- >> Linux-audit mailing list >> Linux-audit(a)redhat.com >> https://www.redhat.com/mailman/listinfo/linux-audit -- Linux-audit mailing list Linux-audit(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit

> You can use audit dispatcher to react to audit events.... When u get a > MOUNT event you can see where sr0 is mounted and start a new watch for > that > path. If you are not writing an ISO I think it has to be mounted. I think hooking the udev rules might be better. This would let you check for hot plug events where something is not yet mounted.