reactive audit proposal

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?

Quoted 59 lines · 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.

Quoted 1 line

Thoughts?

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

Quoted 59 lines · EDT Joe Nall

Quoted 59 lines · 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.

Quoted 4 lines

Quoted 1 line

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

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?

I wonder about the case where a system is booted with new media already attached.

Quoted 4 lines · EDT Joe Wulf

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.

Quoted 1 line

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 [email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

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

Quoted 14 lines · Steve Grubb

Quoted 4 lines · EDT Joe Wulf

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.

Quoted 1 line

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

Quoted 6 lines · Burn Alting

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.

Quoted 5 lines

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?

Quoted 6 lines

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.

Quoted 18 lines

Burn

Quoted 15 lines · Steve Grubb

Quoted 4 lines · EDT Joe Wulf

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.

Quoted 2 lines

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 <[email protected]>
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

Hello,

Answering both emails at once.

Quoted 7 lines · EDT Richard Guy Briggs

Quoted 6 lines · Burn Alting

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.

Quoted 5 lines

Quoted 5 lines

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.

Quoted 6 lines

Quoted 6 lines

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.

Quoted 4 lines

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

Quoted 22 lines

This makes it easier to lock things down too.

Quoted 18 lines

Burn

Quoted 15 lines · Steve Grubb

Quoted 4 lines · EDT Joe Wulf

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.

Quoted 2 lines

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

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.