On Tuesday, May 12, 2020 8:31:45 PM EDT Joe Nall wrote: If you do cat /proc/mounts do you see 10k entries? And do you want them or do you think they are harmful? -Steve

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. Thank you. R,-Joe Wulf PS resent, as the first time I'd only emailed Steve my reply. On Tuesday, May 12, 2020, 8:22:48 PM EDT, Steve Grubb <sgrubb(a)redhat.com&gt; 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? -Steve -- Linux-audit mailing list Linux-audit(a)redhat.com 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 On Wed, 2020-05-13 at 14:03 -0400, Steve Grubb wrote:

Hello, Answering both emails at once. On Thursday, May 14, 2020 9:32:21 AM EDT Richard Guy Briggs wrote: libudev has a function that looks up device from a path. I was planning to use that. 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. 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. 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

On 5/12/20 6:22 PM, Steve Grubb wrote: 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