2:16 p.m.
Hi Burn, and all,
I've been aware of this issue for a while now, but wasn't directly
working on it. Now that I'm taking a closer look at this issue, I am
wondering 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/...
It has tools to generate baseline lists of devices, but this is only for
usb. Other interfaces would need to be appropriately instrumented.
- RGB
--
Richard Guy Briggs <rgb(a)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
3:27 a.m.
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/...
It has tools to generate baseline lists of devices, but this is only
forusb. Other interfaces would need to be appropriately instrumented.
- RGB
--Richard Guy Briggs <rgb(a)redhat.com>Sr. S/W Engineer, Kernel Security, Base
Operating SystemsRemote, Ottawa, Red Hat CanadaIRC: rgb, SunRaycerVoice:
+1.647.777.2635, Internal: (81) 32635
7:43 a.m.
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
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/...
>
> It has tools to generate baseline lists of devices, but this is only
> forusb. Other interfaces would need to be appropriately instrumented.
> - RGB
> --Richard Guy Briggs <rgb(a)redhat.com>Sr. S/W Engineer, Kernel Security, Base
> Operating SystemsRemote, Ottawa, Red Hat CanadaIRC: rgb, SunRaycerVoice:
> +1.647.777.2635, Internal: (81) 32635
--Linux-audit mailing listLinux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
9:18 a.m.
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/...
> >
> > 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 <rgb(a)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
2481
days inactive
2482
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
Burn Alting -
Richard Guy Briggs