CD Burner Auditing
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
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.
Quoted 19 lines · Kevin P. (AS)
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/sr0device 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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Signature · 1 line
Please Donate to www.wikipedia.org
Re: EXT :Re: CD Burner Auditing
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
Quoted 32 lines · Satish Chandra Kilaru
One way is to watch for the main folder where
/dev/sr0is 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) <[email protected] <mailto:[email protected]>> 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/sr0device 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 [email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/linux-auditSignature · 1 line
Please Donate to www.wikipedia.org <http://www.wikipedia.org>
Re: EXT :Re: CD Burner Auditing
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.
Quoted 51 lines · Kevin P. (AS)
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/sr0is 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) <[email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>
Quoted 12 lines
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/sr0device 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?Quoted 9 lines
Any suggestions are welcome.
Kevin
--
Linux-audit mailing list [email protected]<javascript:_e(%7B%7D,'cvml','[email protected]');>
https://www.redhat.com/mailman/listinfo/linux-audit--
Please Donate to www.wikipedia.org
Signature · 1 line
Please Donate to www.wikipedia.org
Re: EXT :Re: CD Burner Auditing
Does the audit subsystem have the ability to dynamically create new auditing rules using another event as the trigger?
Any examples on how to implement that?
Kevin
Quoted 62 lines · Satish Chandra Kilaru
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) <[email protected] <mailto:[email protected]>> 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
Quoted 41 lines · Satish Chandra Kilaru
One way is to watch for the main folder where
/dev/sr0is 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) <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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/sr0device 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 [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>
https://www.redhat.com/mailman/listinfo/linux-audit--
Please Donate to www.wikipedia.org <http://www.wikipedia.org>Signature · 1 line
Please Donate to www.wikipedia.org <http://www.wikipedia.org>
Re: EXT :Re: CD Burner Auditing
[root@express april12th]# cat /etc/audisp/plugins.d/test.conf
# This file controls the configuration of the
# af_unix socket plugin. It simply takes events # and writes them to a unix domain socket. This # plugin can take 2 arguments, the path for the # socket and the socket permissions in octal.
active = yes
direction = out
path = /root/python/auevent_parser.py <-- my script #path = /tmp/log_date
type = always
args = /usr/local/cache1/testau.log
format = string
auevent_parser.py will launched by audispd when auditd starts. And all the events that are sent to audit.log are also sent to this script on stdin. You can read the events and filter out what u dont need. When u see any kind access of /my/sensitive/content then insert a rule using 'auditctl
-a'
Quoted 76 lines · Kevin P. (AS)
Does the audit subsystem have the ability to dynamically create new
auditing rules using another event as the trigger?Any examples on how to implement that?
Kevin
On 04/22/2014 03:39 PM, Satish Chandra Kilaru wrote:
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.Quoted 46 lines · Kevin P. (AS)
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/sr0is 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.Quoted 10 lines · Kevin P. (AS)
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/sr0device 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?Quoted 9 lines
Any suggestions are welcome.
Kevin
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-auditQuoted 5 lines
--
Please Donate to www.wikipedia.org--
Please Donate to www.wikipedia.org
Signature · 1 line
Please Donate to www.wikipedia.org
Re: EXT :Re: CD Burner Auditing
In reply to Boyce, Kevin P. (AS)Quoted 2 lines · Kevin P.
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.
-Steve
Re: EXT :Re: CD Burner Auditing
Quoted 10 lines · Steve Grubb
Quoted 2 lines · Kevin P.
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
Re: EXT :Re: CD Burner Auditing
Steve,
The main challenge for this solution is the definition of all audit events that imply removable media has been attached. 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
Forbidden
You don't have permission to
access /sgrubb/audit/reactive/reactive-audit-thesis.pdf on this server.
Rgds
Quoted 27 lines · Steve Grubb
Quoted 10 lines · Steve Grubb
Quoted 2 lines · Kevin P.
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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Re: EXT :Re: CD Burner Auditing
Quoted 4 lines · Burn Alting
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.
Quoted 8 lines
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
Quoted 33 lines · Steve Grubb
Quoted 32 lines · Steve Grubb
Quoted 14 lines · Kevin P.
Quoted 2 lines
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
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Re: EXT :Re: CD Burner Auditing
Quoted 8 lines · Steve Grubb
Quoted 4 lines · Burn Alting
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.
While not exactly targeting the same data egress vector, we utilize a set of udev scripts to monitor USB device insertions while having the usb_storage module removed.
You can find more information https://github.com/RedHatGov/rhel6-hardening/pull/1
I haven’t done any investigation when a USB CD/DVD Writer is inserted though. Nor have I investigated what events are triggered when a blank CD is inserted in to a CD writer. Thought this might help.
-josh
Quoted 53 lines
Quoted 9 lines
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 inFixed. Thanks.
-Steve
Quoted 25 lines · Steve Grubb
Quoted 24 lines · Steve Grubb
Quoted 14 lines · Kevin P.
Quoted 2 lines
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.
Quoted 8 lines
Quoted 8 lines
I would like to hear feedback on this patch to see what others think.
-Steve
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Re: EXT :Re: CD Burner Auditing
In reply to Satish Chandra KilaruQuoted 3 lines · Satish Chandra Kilaru
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 dd on devices that are not mounted.
Quoted 3 lines
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.
-Steve
Re: EXT :Re: CD Burner Auditing
Quoted 7 lines · Steve Grubb
Quoted 4 lines
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.
A long time ago during the RHEL5 LSPP certification, there was a project created to help audit device allocation:
http://sourceforge.net/projects/devallocator/
There were 2 audit events created to assist in this. But if I recall, there was a decision made to not support hot plug events. I forget why. The main thing is that the code has the event in it formatted correctly. udev could be patched to provide this event.
-Steve
Re: EXT :Re: CD Burner Auditing
For what it's worth, I believe one possible solution for this would be a table in the kernel that maintains a list of currently attached removable media. Perhaps this could be an extension of udev. One point though, the definition of what is 'removable' would need to be configurable.
Once such a table exists, a auditing control could be to record all files read or written to devices found in this table. This would cover the use cases of files written to mounted devices and those to a raw device via say, dd.
See https://bugzilla.redhat.com/show_bug.cgi?id=967241 for a feature request marker for this requirement.
Rgds
Quoted 25 lines · Steve Grubb
Quoted 7 lines · Steve Grubb
Quoted 4 lines
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.
A long time ago during the RHEL5 LSPP certification, there was a project created to help audit device allocation:
http://sourceforge.net/projects/devallocator/
There were 2 audit events created to assist in this. But if I recall, there was a decision made to not support hot plug events. I forget why. The main thing is that the code has the event in it formatted correctly. udev could be patched to provide this event.
-Steve
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit