CD Burner Auditing

CD Burner Auditing

[Boyce, 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/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

Re: CD Burner Auditing

[Satish Chandra Kilaru]

[-- Attachment #1.1: Type: text/plain, Size: 1267 bytes --]

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@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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>



-- 
Please Donate to www.wikipedia.org

[-- Attachment #1.2: Type: text/html, Size: 1853 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: EXT :Re: CD Burner Auditing

[Boyce, Kevin P. (AS)]

[-- Attachment #1.1: Type: text/plain, Size: 1861 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 3443 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: EXT :Re: CD Burner Auditing

[Satish Chandra Kilaru]

[-- Attachment #1.1: Type: text/plain, Size: 2366 bytes --]

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

-- 
Please Donate to www.wikipedia.org

[-- Attachment #1.2: Type: text/html, Size: 3871 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: EXT :Re: CD Burner Auditing

[Boyce, Kevin P. (AS)]

[-- Attachment #1.1: Type: text/plain, Size: 2934 bytes --]

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.
>
> On Tuesday, April 22, 2014, Boyce, Kevin P. (AS) <kevin.boyce@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@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@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>


[-- Attachment #1.2: Type: text/html, Size: 5631 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: EXT :Re: CD Burner Auditing

[Satish Chandra Kilaru]

[-- Attachment #1.1: Type: text/plain, Size: 3468 bytes --]

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




On Tue, Apr 22, 2014 at 3:44 PM, Boyce, Kevin P. (AS)
<kevin.boyce@ngc.com>wrote:

>  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.
>
> On Tuesday, April 22, 2014, Boyce, Kevin P. (AS) <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@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@redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-audit
>>>
>>
>>
>>
>>  --
>> Please Donate to www.wikipedia.org
>>
>>
>>
>
> --
> Please Donate to www.wikipedia.org
>
>
>


-- 
Please Donate to www.wikipedia.org

[-- Attachment #1.2: Type: text/html, Size: 6511 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: EXT :Re: CD Burner Auditing

[Steve Grubb]

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.

-Steve

Re: EXT :Re: CD Burner Auditing

[Steve Grubb]

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

Re: EXT :Re: CD Burner Auditing

[Burn Alting]

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


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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: EXT :Re: CD Burner Auditing

[Steve Grubb]

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@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit

Re: EXT :Re: CD Burner Auditing

[Josh]

On Apr 22, 2014, at 6:11 PM, Steve Grubb <sgrubb@redhat.com> wrote:

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

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
> 
>> 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@redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-audit
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: EXT :Re: CD Burner Auditing

[Steve Grubb]

On Tuesday, April 22, 2014 03:39:14 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 dd on devices that are not mounted.


> 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

[Steve Grubb]

On Tuesday, April 22, 2014 04:02:47 PM Steve Grubb wrote:
> > 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

[Burn Alting]

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

On Tue, 2014-04-22 at 16:43 -0400, Steve Grubb wrote:
> On Tuesday, April 22, 2014 04:02:47 PM Steve Grubb wrote:
> > > 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
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit