PresentDevicePolicy: allow combination of keep and apply-policy
Hi,
I think it would be great if PresentDevicePolicy would allow a combination of keep and apply-policy. When setting the PresentDevicePolicy to keep and then adding a rule to block a device to the rulefile, a reboot with the device attached would allow the device. A combination of keep and apply-policy would then only fallback to keep if there is no policy defined for the device.
Interesting. Is ImplicitDevicePolicy evaluated at all when PresentDevicePolicy is used?
Interesting. Is
ImplicitDevicePolicyevaluated at all whenPresentDevicePolicyis used?
There is no ImplicityDevicePolicy, i guess you mean ImplicitPolicyTarget? Its not evaluated, as far as I can say from my tests. (I have ImplicitPolicyTarget=block and PresentDevicePolicy=keep and one device blocked in the rule file. After a reboot usbguard list-rules lists the rules correct, but usbguard list-devices lists them all as allowed)
I guess I would expect a behavior like in some firewall solutions, with the most specific rule being the one applied.
This is the context around this question: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928032.
Generally, to achieve this behaviour, you would set PresentDevicePolicy=apply-policy and add your rules (rules.conf) which may fallback on ImplicitPolicyTarget.
I'm actually wondering if USBGuard should drop the keep option. By definition, it decides on which devices are authorised or blocked. Leaving a "floating" state like that just bring confusion on what to expect and how to handle it. (This would mean move the PresentControllerPolicy to allow).
@dkopecek and @radosroka What do you think our approach should be here? Thanks
I can see a benefit of keep option in respecting device in blocked state.
This is the context around this question: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928032.
Generally, to achieve this behaviour, you would set
PresentDevicePolicy=apply-policyand add your rules (rules.conf) which may fallback onImplicitPolicyTarget.I'm actually wondering if USBGuard should drop the
keepoption. By definition, it decides on which devices are authorised or blocked. Leaving a "floating" state like that just bring confusion on what to expect and how to handle it. (This would mean move thePresentControllerPolicytoallow).
But it does make sense in the way how you described it.