* reactive audit proposal @ 2020-05-13 0:22 Steve Grubb 2020-05-13 0:31 ` Joe Nall ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Steve Grubb @ 2020-05-13 0:22 UTC (permalink / raw) To: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: reactive audit proposal 2020-05-13 0:22 reactive audit proposal Steve Grubb @ 2020-05-13 0:31 ` Joe Nall 2020-05-13 0:36 ` Steve Grubb [not found] ` <2037581034.269445.1589390222295@mail.yahoo.com> 2020-05-15 15:00 ` Lenny Bruzenak 2 siblings, 1 reply; 10+ messages in thread From: Joe Nall @ 2020-05-13 0:31 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: reactive audit proposal 2020-05-13 0:31 ` Joe Nall @ 2020-05-13 0:36 ` Steve Grubb 2020-05-13 16:47 ` Joe Nall 0 siblings, 1 reply; 10+ messages in thread From: Steve Grubb @ 2020-05-13 0:36 UTC (permalink / raw) To: Joe Nall; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: reactive audit proposal 2020-05-13 0:36 ` Steve Grubb @ 2020-05-13 16:47 ` Joe Nall 0 siblings, 0 replies; 10+ messages in thread From: Joe Nall @ 2020-05-13 16:47 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <2037581034.269445.1589390222295@mail.yahoo.com>]
* Re: reactive audit proposal [not found] ` <2037581034.269445.1589390222295@mail.yahoo.com> @ 2020-05-13 18:03 ` Steve Grubb 2020-05-14 8:55 ` Burn Alting 0 siblings, 1 reply; 10+ messages in thread From: Steve Grubb @ 2020-05-13 18:03 UTC (permalink / raw) To: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: reactive audit proposal 2020-05-13 18:03 ` Steve Grubb @ 2020-05-14 8:55 ` Burn Alting 2020-05-14 13:32 ` Richard Guy Briggs 0 siblings, 1 reply; 10+ messages in thread From: Burn Alting @ 2020-05-14 8:55 UTC (permalink / raw) To: Steve Grubb, linux-audit [-- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: reactive audit proposal 2020-05-14 8:55 ` Burn Alting @ 2020-05-14 13:32 ` Richard Guy Briggs 2020-05-14 14:47 ` Steve Grubb 0 siblings, 1 reply; 10+ messages in thread From: Richard Guy Briggs @ 2020-05-14 13:32 UTC (permalink / raw) To: burn; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: reactive audit proposal 2020-05-14 13:32 ` Richard Guy Briggs @ 2020-05-14 14:47 ` Steve Grubb 2020-05-14 15:14 ` Richard Guy Briggs 0 siblings, 1 reply; 10+ messages in thread From: Steve Grubb @ 2020-05-14 14:47 UTC (permalink / raw) To: Richard Guy Briggs; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: reactive audit proposal 2020-05-14 14:47 ` Steve Grubb @ 2020-05-14 15:14 ` Richard Guy Briggs 0 siblings, 0 replies; 10+ messages in thread From: Richard Guy Briggs @ 2020-05-14 15:14 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: reactive audit proposal 2020-05-13 0:22 reactive audit proposal Steve Grubb 2020-05-13 0:31 ` Joe Nall [not found] ` <2037581034.269445.1589390222295@mail.yahoo.com> @ 2020-05-15 15:00 ` Lenny Bruzenak 2 siblings, 0 replies; 10+ messages in thread From: Lenny Bruzenak @ 2020-05-15 15:00 UTC (permalink / raw) To: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-05-15 15:00 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-13 0:22 reactive audit proposal Steve Grubb 2020-05-13 0:31 ` Joe Nall 2020-05-13 0:36 ` Steve Grubb 2020-05-13 16:47 ` Joe Nall [not found] ` <2037581034.269445.1589390222295@mail.yahoo.com> 2020-05-13 18:03 ` Steve Grubb 2020-05-14 8:55 ` Burn Alting 2020-05-14 13:32 ` Richard Guy Briggs 2020-05-14 14:47 ` Steve Grubb 2020-05-14 15:14 ` Richard Guy Briggs 2020-05-15 15:00 ` Lenny Bruzenak
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.