On 2020-01-23 00:43, Burn Alting wrote: > Well, there is one thing we may need to change. > If USBGuard is configured to sent it's logs to auditd generating a > USER_DEVICE event > type, we are going to have to add some new keys to the typetab.h table so > that one > can interpret some of the USBGuard keys. Unfortunately, USBGuard appears to > decide > to encode a key's value dependant on it's content (e.g. embedded spaces or > quotes) > not the key. I am not sure if ausearch's interpret code can decide on the fly > whether to unescape a possible encoded key's value or that will need to be > built in. > Also any down-stream processing of interpreted values may be challenging > given an > example key value pair > likeencoded:device_rule=616C6C6F7720696420316436623A303030322073657269616C202230303 > 0303A30303A31612E3022206E616D6520224548434920486F737420436F6E74726F6C6C6572222068617 > 3682022656A3157566564794C79554D4C6951787A45637277625934357A436F64775638354B7A7937686 > D324776343D2220706172656E742D686173682022652F5257306D4D624D2B54534651787052694D45664 > C372F33524A664B5664716666426D39463571412B453D22207669612D706F72742022757362312220776 > 974682D696E746572666163652030393A30303A3030decoded:device_rule=allow id > 1d6b:0002 > serial "0000:00:1a.0" name "EHCI Host Controller" hash > "ej1WVedyLyUMLiQxzEcrwbY45zCodwV85Kzy7hm2Gv4=" parent-hash > "e/RW0mMbM+TSFQxpRiMEfL7/3RJfKVdqffBm9F5qA+E=" via-port "usb1" with-interface > 09:00:00
Yes, fields need to be consistently encoded since the parser isn't able to detect that. > On Wed, 2020-01-22 at 20:27 +1100, Burn Alting wrote: > > Richard, > > > > On the surface, it appears to have value, but as you say it would need to be > > extended to other traditional, and non-traditional, removable media. > > Further, the > > initial appeal in having the capability directly within the kernel was to > > make it > > a little more difficult to subvert, centralise auditing policy/monitoring > > and, if > > frame-worked appropriately, easily extensible to other than USB media types > > (which > > was the basis for the Proof of Concept developed by RedHat back in 2016). > > > > I have not used USBGuard myself, so will do some experimentation and report > > back. > > > > Regards > > > > On Tue, 2020-01-21 at 15:16 -0500, Richard Guy Briggs wrote: > > > Hi Burn, and all, > > > I've been aware of this issue for a while now, but wasn't directlyworking > > > on > > > it. Now that I'm taking a closer look at this issue, I amwondering how > > > much > > > USBGuard changes the equation? > > > https://www.kernel.org/doc/Documentation/usb/authorization.txt > > > https://usbguard.github.io/ > > > https://github.com/USBGuard/usbguard > > > > > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using-usbguard > > > > > > It has tools to generate baseline lists of devices, but this is only > > > forusb. Other interfaces would need to be appropriately instrumented. > > > - RGB - 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 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
