reactive audit proposal

reactive audit proposal

[Steve Grubb]

Hello,

I wanted to run this by the crowd to see what people's reaction might be.

The audit system sometimes needs to have rules applied when something
happens. For example, if someone plugs in a USB flash drive, the system
creates the device in /dev and then automatically mounts it under some
circumstances.

I would propose 2 new additions to the audit rule syntax: on-mount and
on-login.These rules would be in a separate file from the main audit rules.
When a file system is mounted, /proc/mounts changes and the mount table can
be scanned to see if something new is there. In this way we can reliably
detect newly mounted filesystems. We can then match against a specifier to
see if this is a file system in which we want to apply new rules. If so, we
send the new rules to the kernel. When the device is unmounted, the kernel
drops all watches on that file system. So, we only need to worry about when
a device is mounted.

This works good for anything that gets mounted. But it is also possible for
a USB flash drive to be accessed as a block device, such as the dd utility.
If we had to detect device discovery, there is a netlink group,
NETLINK_KOBJECT_UEVENT which we could monitor for events. The only thing is
that we could only detect open/read/write/close/ioctl/lseek. And we probably
do not want to monitor anything except block devices.

It may also be possible to poll /sys/block to watch for changes. This might
be easier as the names are more friendly. This would take some research to
see if its even possible.

The rule syntax could look something like:
on=mount mount=/run/user/1000 : -a exit,always ...
on=device device=/dev/sdd : -a exit,always ...

The on-login event would simply watch the audit trail for any AUDIT_LOGIN
events. That event can be parsed to get the new auid. If the auid matches
any rules, then it will load them into the kernel. To remove the rules, we
could watch for the AUDIT_USER_END event. The only issue is that we would
need to track how many sessions the user has open and remove the rules only
when the last session closes out.

The rules for this might look something like this:
on=login auid=1000 : -a exit,always ...

The question is whether or not this should be done as part of the audit
daemon or as a plugin for the audit daemon. One advantage of doing this as
a plugin is that it will keep the audit daemon focused on getting events
and distributing them. Any programming mistake in the plugin will crash it
and not the daemon. The tradeoff is that it will get the event slightly
after auditd sees it. This only matters for the on-login functionality. The
device and mount events come from an entirely different source. And I'm sure 
that in every case, the program will react faster than a user possibily can 
winning the race evry time.

Thoughts?

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: reactive audit proposal

[Joe Nall]

> On May 12, 2020, at 7:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> 
> Hello,
> 
> I wanted to run this by the crowd to see what people's reaction might be.
> 
> The audit system sometimes needs to have rules applied when something
> happens. For example, if someone plugs in a USB flash drive, the system
> creates the device in /dev and then automatically mounts it under some
> circumstances.
> 
> I would propose 2 new additions to the audit rule syntax: on-mount and
> on-login.These rules would be in a separate file from the main audit rules.
> When a file system is mounted, /proc/mounts changes and the mount table can
> be scanned to see if something new is there. In this way we can reliably
> detect newly mounted filesystems. We can then match against a specifier to
> see if this is a file system in which we want to apply new rules. If so, we
> send the new rules to the kernel. When the device is unmounted, the kernel
> drops all watches on that file system. So, we only need to worry about when
> a device is mounted.
> 
> This works good for anything that gets mounted. But it is also possible for
> a USB flash drive to be accessed as a block device, such as the dd utility.
> If we had to detect device discovery, there is a netlink group,
> NETLINK_KOBJECT_UEVENT which we could monitor for events. The only thing is
> that we could only detect open/read/write/close/ioctl/lseek. And we probably
> do not want to monitor anything except block devices.
> 
> It may also be possible to poll /sys/block to watch for changes. This might
> be easier as the names are more friendly. This would take some research to
> see if its even possible.
> 
> The rule syntax could look something like:
> on=mount mount=/run/user/1000 : -a exit,always ...
> on=device device=/dev/sdd : -a exit,always ...
> 
> The on-login event would simply watch the audit trail for any AUDIT_LOGIN
> events. That event can be parsed to get the new auid. If the auid matches
> any rules, then it will load them into the kernel. To remove the rules, we
> could watch for the AUDIT_USER_END event. The only issue is that we would
> need to track how many sessions the user has open and remove the rules only
> when the last session closes out.
> 
> The rules for this might look something like this:
> on=login auid=1000 : -a exit,always ...
> 
> The question is whether or not this should be done as part of the audit
> daemon or as a plugin for the audit daemon. One advantage of doing this as
> a plugin is that it will keep the audit daemon focused on getting events
> and distributing them. Any programming mistake in the plugin will crash it
> and not the daemon. The tradeoff is that it will get the event slightly
> after auditd sees it. This only matters for the on-login functionality. The
> device and mount events come from an entirely different source. And I'm sure 
> that in every case, the program will react faster than a user possibily can 
> winning the race evry time.
> 
> Thoughts?

Would bind mounts trigger these rules? I'm sitting next to a box with 10k polyinstantiated bind mounts right now.

joe



--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: reactive audit proposal

[Steve Grubb]

On Tuesday, May 12, 2020 8:31:45 PM EDT Joe Nall wrote:
> > On May 12, 2020, at 7:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > 
> > Hello,
> > 
> > I wanted to run this by the crowd to see what people's reaction might be.
> > 
> > The audit system sometimes needs to have rules applied when something
> > happens. For example, if someone plugs in a USB flash drive, the system
> > creates the device in /dev and then automatically mounts it under some
> > circumstances.
> > 
> > I would propose 2 new additions to the audit rule syntax: on-mount and
> > on-login.These rules would be in a separate file from the main audit
> > rules. When a file system is mounted, /proc/mounts changes and the mount
> > table can be scanned to see if something new is there. In this way we
> > can reliably detect newly mounted filesystems. We can then match against
> > a specifier to see if this is a file system in which we want to apply
> > new rules. If so, we send the new rules to the kernel. When the device
> > is unmounted, the kernel drops all watches on that file system. So, we
> > only need to worry about when a device is mounted.
> > 
> > This works good for anything that gets mounted. But it is also possible
> > for a USB flash drive to be accessed as a block device, such as the dd
> > utility. If we had to detect device discovery, there is a netlink group,
> > NETLINK_KOBJECT_UEVENT which we could monitor for events. The only thing
> > is that we could only detect open/read/write/close/ioctl/lseek. And we
> > probably do not want to monitor anything except block devices.
> > 
> > It may also be possible to poll /sys/block to watch for changes. This
> > might be easier as the names are more friendly. This would take some
> > research to see if its even possible.
> > 
> > The rule syntax could look something like:
> > on=mount mount=/run/user/1000 : -a exit,always ...
> > on=device device=/dev/sdd : -a exit,always ...
> > 
> > The on-login event would simply watch the audit trail for any AUDIT_LOGIN
> > events. That event can be parsed to get the new auid. If the auid matches
> > any rules, then it will load them into the kernel. To remove the rules,
> > we
> > could watch for the AUDIT_USER_END event. The only issue is that we would
> > need to track how many sessions the user has open and remove the rules
> > only when the last session closes out.
> > 
> > The rules for this might look something like this:
> > on=login auid=1000 : -a exit,always ...
> > 
> > The question is whether or not this should be done as part of the audit
> > daemon or as a plugin for the audit daemon. One advantage of doing this
> > as
> > a plugin is that it will keep the audit daemon focused on getting events
> > and distributing them. Any programming mistake in the plugin will crash
> > it
> > and not the daemon. The tradeoff is that it will get the event slightly
> > after auditd sees it. This only matters for the on-login functionality.
> > The device and mount events come from an entirely different source. And
> > I'm sure that in every case, the program will react faster than a user
> > possibily can winning the race evry time.
> > 
> > Thoughts?
> 
> Would bind mounts trigger these rules? I'm sitting next to a box with 10k
> polyinstantiated bind mounts right now.

If you do cat /proc/mounts  do you see 10k entries? And do you want them or 
do you think they are harmful?

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: reactive audit proposal

[Joe Nall]

> On May 12, 2020, at 7:36 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> 
> On Tuesday, May 12, 2020 8:31:45 PM EDT Joe Nall wrote:
>>> On May 12, 2020, at 7:22 PM, Steve Grubb <sgrubb@redhat.com> wrote:
>>> 
>>> Hello,
>>> 
>>> I wanted to run this by the crowd to see what people's reaction might be.
>>> 
>>> The audit system sometimes needs to have rules applied when something
>>> happens. For example, if someone plugs in a USB flash drive, the system
>>> creates the device in /dev and then automatically mounts it under some
>>> circumstances.
>>> 
>>> I would propose 2 new additions to the audit rule syntax: on-mount and
>>> on-login.These rules would be in a separate file from the main audit
>>> rules. When a file system is mounted, /proc/mounts changes and the mount
>>> table can be scanned to see if something new is there. In this way we
>>> can reliably detect newly mounted filesystems. We can then match against
>>> a specifier to see if this is a file system in which we want to apply
>>> new rules. If so, we send the new rules to the kernel. When the device
>>> is unmounted, the kernel drops all watches on that file system. So, we
>>> only need to worry about when a device is mounted.
>>> 
>>> This works good for anything that gets mounted. But it is also possible
>>> for a USB flash drive to be accessed as a block device, such as the dd
>>> utility. If we had to detect device discovery, there is a netlink group,
>>> NETLINK_KOBJECT_UEVENT which we could monitor for events. The only thing
>>> is that we could only detect open/read/write/close/ioctl/lseek. And we
>>> probably do not want to monitor anything except block devices.
>>> 
>>> It may also be possible to poll /sys/block to watch for changes. This
>>> might be easier as the names are more friendly. This would take some
>>> research to see if its even possible.
>>> 
>>> The rule syntax could look something like:
>>> on=mount mount=/run/user/1000 : -a exit,always ...
>>> on=device device=/dev/sdd : -a exit,always ...
>>> 
>>> The on-login event would simply watch the audit trail for any AUDIT_LOGIN
>>> events. That event can be parsed to get the new auid. If the auid matches
>>> any rules, then it will load them into the kernel. To remove the rules,
>>> we
>>> could watch for the AUDIT_USER_END event. The only issue is that we would
>>> need to track how many sessions the user has open and remove the rules
>>> only when the last session closes out.
>>> 
>>> The rules for this might look something like this:
>>> on=login auid=1000 : -a exit,always ...
>>> 
>>> The question is whether or not this should be done as part of the audit
>>> daemon or as a plugin for the audit daemon. One advantage of doing this
>>> as
>>> a plugin is that it will keep the audit daemon focused on getting events
>>> and distributing them. Any programming mistake in the plugin will crash
>>> it
>>> and not the daemon. The tradeoff is that it will get the event slightly
>>> after auditd sees it. This only matters for the on-login functionality.
>>> The device and mount events come from an entirely different source. And
>>> I'm sure that in every case, the program will react faster than a user
>>> possibily can winning the race evry time.
>>> 
>>> Thoughts?
>> 
>> Would bind mounts trigger these rules? I'm sitting next to a box with 10k
>> polyinstantiated bind mounts right now.
> 
> If you do cat /proc/mounts do you see 10k entries?
No. This is over many users and applications launched with different contexts.

This morning, on a machine with one user, as a permissive root/sysadm_t:
cat /proc/*/mounts | grep inst | wc -l
2046
and from a user terminal session:
cat /proc/mounts | wc -l
218

> And do you want them or do you think they are harmful?

I thought they were all intentional when I started typing, but you have sent me down a rabbit hole looking into this :(

I like this idea, I just want to make sure that our atypical use case does not break it or vice versa.

cheers,
joe

> 
> -Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: reactive audit proposal

[Steve Grubb]

On Wednesday, May 13, 2020 1:17:02 PM EDT Joe Wulf wrote:
> What you propose is a sound enhancement.
> I have no preference for the choice between incorporate this in the audit
> daemon versus a plugin.What would be the effort to switch from one to the
> other if later on you should find the first choice wasn't as optimal?

Well, the main idea for a plugin is not to stop processing events. Busy 
systems need to keep focused on unloading the kernel backlog.
 
> I wonder about the case where a system is booted with new media already
> attached.

During initialization, it runs through the mount table just as if the mount 
table was changed. So, it has the opportunity to apply rules during init. I'm 
borrowing code from fapolicyd which has this nicely solved. (It's one of my 
other projects.)

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: reactive audit proposal

[Burn Alting]

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

I also endorse such a change. 
There is a significant gap in recoding removable media activity (see 
https://bugzilla.redhat.com/show_bug.cgi?id=967241) and the on_mount could go a
reasonable  way to address this, including making use of the
NETLUNK_KOBJECT_UEVENTnetlink group or  /sys/block polling to assist with device
discovery.
Secondly, being able to react to a login/logout event also opens up interesting
opportunity for targetedevent generation.
That said, I believe that Juro Hlista did some work on this back around 2010. He did
this via a plugin. His solutionwas a little more generic. Should we be looking at
that as a solution as well? One element I do remember from hiswork, was that there
was a potential gap in the time to react to a trigger firing and the result was that
one was notguaranteed to implement the new rules immediately. I assume to treat this
gap, the rules could be preloaded and the 'trigger' action could just move the
'dormant' rules, already in core, to the 'active' list.
Burn
On Wed, 2020-05-13 at 14:03 -0400, Steve Grubb wrote:
> On Wednesday, May 13, 2020 1:17:02 PM EDT Joe Wulf wrote:
> > What you propose is a sound enhancement.I have no preference for the choice
> > between incorporate this in the auditdaemon versus a plugin.What would be the
> > effort to switch from one to theother if later on you should find the first
> > choice wasn't as optimal?
> 
> Well, the main idea for a plugin is not to stop processing events. Busy systems
> need to keep focused on unloading the kernel backlog. 
> > I wonder about the case where a system is booted with new media alreadyattached.
> 
> During initialization, it runs through the mount table just as if the mount table
> was changed. So, it has the opportunity to apply rules during init. I'm borrowing
> code from fapolicyd which has this nicely solved. (It's one of my other projects.)
> -Steve
> 
> 
> --Linux-audit mailing listLinux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
> 

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

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

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: reactive audit proposal

[Richard Guy Briggs]

On 2020-05-14 18:55, Burn Alting wrote:
> I also endorse such a change. 
> There is a significant gap in recoding removable media activity (see 
> https://bugzilla.redhat.com/show_bug.cgi?id=967241) and the on_mount could go a
> reasonable  way to address this, including making use of the
> NETLUNK_KOBJECT_UEVENTnetlink group or  /sys/block polling to assist with device
> discovery.
> Secondly, being able to react to a login/logout event also opens up interesting
> opportunity for targetedevent generation.
> That said, I believe that Juro Hlista did some work on this back around 2010. He did
> this via a plugin. His solutionwas a little more generic. Should we be looking at
> that as a solution as well? One element I do remember from hiswork, was that there
> was a potential gap in the time to react to a trigger firing and the result was that
> one was notguaranteed to implement the new rules immediately. I assume to treat this
> gap, the rules could be preloaded and the 'trigger' action could just move the
> 'dormant' rules, already in core, to the 'active' list.

I was going to say, this one feels like there are a set of rules that
should just be present from the get-go and not dynamic.  If we already
know what we are looking for (monitor a specific user, or monitor a
specific device) then just add those rules to the permenent set.

This makes it easier to lock things down too.

> Burn
> On Wed, 2020-05-13 at 14:03 -0400, Steve Grubb wrote:
> > On Wednesday, May 13, 2020 1:17:02 PM EDT Joe Wulf wrote:
> > > What you propose is a sound enhancement.I have no preference for the choice
> > > between incorporate this in the auditdaemon versus a plugin.What would be the
> > > effort to switch from one to theother if later on you should find the first
> > > choice wasn't as optimal?
> > 
> > Well, the main idea for a plugin is not to stop processing events. Busy systems
> > need to keep focused on unloading the kernel backlog. 
> > > I wonder about the case where a system is booted with new media alreadyattached.
> > 
> > During initialization, it runs through the mount table just as if the mount table
> > was changed. So, it has the opportunity to apply rules during init. I'm borrowing
> > code from fapolicyd which has this nicely solved. (It's one of my other projects.)
> > -Steve

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: reactive audit proposal

[Steve Grubb]

Hello,

Answering both emails at once.

On Thursday, May 14, 2020 9:32:21 AM EDT Richard Guy Briggs wrote:
> On 2020-05-14 18:55, Burn Alting wrote:
> > I also endorse such a change.
> > There is a significant gap in recoding removable media activity (see
> > https://bugzilla.redhat.com/show_bug.cgi?id=967241) and the on_mount
> > could go a reasonable  way to address this, including making use of the
> > NETLUNK_KOBJECT_UEVENTnetlink group or  /sys/block polling to assist with
> > device discovery.

libudev has a function that looks up device from a path. I was planning to use that.

> > Secondly, being able to react to a login/logout event also opens up
> > interesting opportunity for targetedevent generation.
> > That said, I believe that Juro Hlista did some work on this back around
> > 2010. He did this via a plugin. His solutionwas a little more generic.
> > Should we be looking at that as a solution as well?

I really don't know that code. It was done as a summer research project for
a thesis. I do not know if it is production ready, supportable, or
sustainable. While it may be more general, I remember the code base being
large. Large means complicated. I'd rather narrow the scope and have a small
amount of code that serves a single purpose.

> > One element I do
> > remember from hiswork, was that there was a potential gap in the time to
> > react to a trigger firing and the result was that one was notguaranteed
> > to implement the new rules immediately. I assume to treat this gap, the
> > rules could be preloaded and the 'trigger' action could just move the
> > 'dormant' rules, already in core, to the 'active' list.

I was going to make them memory resident so that searching them is fast.
Watching for mount changes will probably be faster that the general system
because it does not depend on a mount syscall rule to trickle down and then
react. 

In the user case, we would watch for the login event. It should be
able to react before the whole pam cycle finishes. Although we would want to
monitor the progress of pam so that we don't place a rule when the session
never starts due to pam_time voting no. And we'll have to handle a login and
cron jobs differently.
 
> I was going to say, this one feels like there are a set of rules that
> should just be present from the get-go and not dynamic.  If we already
> know what we are looking for (monitor a specific user, or monitor a
> specific device) then just add those rules to the permenent set.

OK, lets give that a try

# auditctl -a always,exit -F dir=/run/media/sgrubb/sandisk/ -F perm=rx -F key=usb-drive
Error sending add rule data request (No such file or directory)

We can't. Also, every single rule we add slows down the system.

-Steve

> This makes it easier to lock things down too.
> 
> > Burn
> > 
> > On Wed, 2020-05-13 at 14:03 -0400, Steve Grubb wrote:
> > > On Wednesday, May 13, 2020 1:17:02 PM EDT Joe Wulf wrote:
> > > > What you propose is a sound enhancement.I have no preference for the
> > > > choice between incorporate this in the auditdaemon versus a
> > > > plugin.What would be the effort to switch from one to theother if
> > > > later on you should find the first choice wasn't as optimal?
> > > 
> > > Well, the main idea for a plugin is not to stop processing events. Busy
> > > systems need to keep focused on unloading the kernel backlog.
> > > 
> > > > I wonder about the case where a system is booted with new media
> > > > alreadyattached.> > 
> > > During initialization, it runs through the mount table just as if the
> > > mount table was changed. So, it has the opportunity to apply rules
> > > during init. I'm borrowing code from fapolicyd which has this nicely
> > > solved. (It's one of my other projects.) -Steve
> 
> - RGB
> 
> --
> Richard Guy Briggs <rgb@redhat.com>
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635




--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: reactive audit proposal

[Richard Guy Briggs]

On 2020-05-14 10:47, Steve Grubb wrote:
> Hello,
> 
> Answering both emails at once.
> 
> On Thursday, May 14, 2020 9:32:21 AM EDT Richard Guy Briggs wrote:
> > On 2020-05-14 18:55, Burn Alting wrote:
> > > I also endorse such a change.
> > > There is a significant gap in recoding removable media activity (see
> > > https://bugzilla.redhat.com/show_bug.cgi?id=967241) and the on_mount
> > > could go a reasonable  way to address this, including making use of the
> > > NETLUNK_KOBJECT_UEVENTnetlink group or  /sys/block polling to assist with
> > > device discovery.
> 
> libudev has a function that looks up device from a path. I was planning to use that.
> 
> > > Secondly, being able to react to a login/logout event also opens up
> > > interesting opportunity for targetedevent generation.
> > > That said, I believe that Juro Hlista did some work on this back around
> > > 2010. He did this via a plugin. His solutionwas a little more generic.
> > > Should we be looking at that as a solution as well?
> 
> I really don't know that code. It was done as a summer research project for
> a thesis. I do not know if it is production ready, supportable, or
> sustainable. While it may be more general, I remember the code base being
> large. Large means complicated. I'd rather narrow the scope and have a small
> amount of code that serves a single purpose.
> 
> > > One element I do
> > > remember from hiswork, was that there was a potential gap in the time to
> > > react to a trigger firing and the result was that one was notguaranteed
> > > to implement the new rules immediately. I assume to treat this gap, the
> > > rules could be preloaded and the 'trigger' action could just move the
> > > 'dormant' rules, already in core, to the 'active' list.
> 
> I was going to make them memory resident so that searching them is fast.
> Watching for mount changes will probably be faster that the general system
> because it does not depend on a mount syscall rule to trickle down and then
> react. 
> 
> In the user case, we would watch for the login event. It should be
> able to react before the whole pam cycle finishes. Although we would want to
> monitor the progress of pam so that we don't place a rule when the session
> never starts due to pam_time voting no. And we'll have to handle a login and
> cron jobs differently.
>  
> > I was going to say, this one feels like there are a set of rules that
> > should just be present from the get-go and not dynamic.  If we already
> > know what we are looking for (monitor a specific user, or monitor a
> > specific device) then just add those rules to the permenent set.
> 
> OK, lets give that a try
> 
> # auditctl -a always,exit -F dir=/run/media/sgrubb/sandisk/ -F perm=rx -F key=usb-drive
> Error sending add rule data request (No such file or directory)
> 
> We can't. Also, every single rule we add slows down the system.

True on both counts.  However, that is also true of the device
monitoring list to a lesser degree...

GHAK12 ( https://github.com/linux-audit/audit-kernel/issues/12 ) may
help with this and the idea has been discussed previously to find a way
to overcome this current limitation of kaudit.

> -Steve
> 
> > This makes it easier to lock things down too.
> > 
> > > Burn
> > > 
> > > On Wed, 2020-05-13 at 14:03 -0400, Steve Grubb wrote:
> > > > On Wednesday, May 13, 2020 1:17:02 PM EDT Joe Wulf wrote:
> > > > > What you propose is a sound enhancement.I have no preference for the
> > > > > choice between incorporate this in the auditdaemon versus a
> > > > > plugin.What would be the effort to switch from one to theother if
> > > > > later on you should find the first choice wasn't as optimal?
> > > > 
> > > > Well, the main idea for a plugin is not to stop processing events. Busy
> > > > systems need to keep focused on unloading the kernel backlog.
> > > > 
> > > > > I wonder about the case where a system is booted with new media
> > > > > alreadyattached.> > 
> > > > During initialization, it runs through the mount table just as if the
> > > > mount table was changed. So, it has the opportunity to apply rules
> > > > during init. I'm borrowing code from fapolicyd which has this nicely
> > > > solved. (It's one of my other projects.) -Steve
> > 
> > - RGB

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: reactive audit proposal

[Lenny Bruzenak]

On 5/12/20 6:22 PM, Steve Grubb wrote:

> It may also be possible to poll /sys/block to watch for changes. This might
> be easier as the names are more friendly. This would take some research to
> see if its even possible.
>
> The rule syntax could look something like:
> on=mount mount=/run/user/1000 : -a exit,always ...
> on=device device=/dev/sdd : -a exit,always ...
>
> The on-login event would simply watch the audit trail for any AUDIT_LOGIN
> events. That event can be parsed to get the new auid. If the auid matches
> any rules, then it will load them into the kernel. To remove the rules, we
> could watch for the AUDIT_USER_END event. The only issue is that we would
> need to track how many sessions the user has open and remove the rules only
> when the last session closes out.
>
> The rules for this might look something like this:
> on=login auid=1000 : -a exit,always ...
>
> The question is whether or not this should be done as part of the audit
> daemon or as a plugin for the audit daemon. One advantage of doing this as
> a plugin is that it will keep the audit daemon focused on getting events
> and distributing them. Any programming mistake in the plugin will crash it
> and not the daemon. The tradeoff is that it will get the event slightly
> after auditd sees it. This only matters for the on-login functionality. The
> device and mount events come from an entirely different source. And I'm sure
> that in every case, the program will react faster than a user possibily can
> winning the race evry time.


Although I like this generally, I also have to say that I'm generally 
apprehensive (OK scared) of dynamic rules.

I think also that while your proposal makes sense for some (likely many) 
use cases, usually not ones I deal with. Controlled spaces don't allow 
USB drives and even so, we detect this adequately now. Have plans of 
using USBGuard to augment that stance.

So in that regard, a plugin would be far better for me so I can disable 
it until it fits the model under which I operate. Just my own small, 
non-standard myopic focus. :-)

I also believe that this has more generic application, and you are 
probably using the USB device as an exemplar. There may be other 
reactive rule use cases I would be inclined to reassess.

The login/user_end event watching does pique my interest...besides 
device insertion I imagine there would be some interesting things you 
could do on the fly with that.

But again for me the strength of locking the rules into place is pretty 
big. I can only imagine what an informed pen test crew would do with 
dynamic rule manipulation.

Thanks Steve!

LCB

-- 
Lenny Bruzenak
MagitekLTD

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit