On Sun, Jul 21, 2019 at 10:20 AM Birger Schacht <bir...@rantanplan.org> wrote: > > Hi, > > On 7/16/19 7:01 PM, Thiébaud Weksteen wrote: > > It might be worth talking about what threat we want to address in the > > default config. In both cases (keep or generate-policy), the kernel > > will be exposed until usbguard is started. If we are considering an > > attacker using a malicious device to target some kernel driver, either > > solution is affected. > > > > In the case of generate-policy, we would prevent further attack > > surface (e.g., if the user has automount enabled in their GUI). > > However, I still think that the "keep" option is more conservative and > > therefore less likely to block a device inadvertently. It may also be > > easier to explain the setup to the user: "any new USB device inserted > > after the daemon started will be blocked" compared to "we have taken a > > snapshot of the devices currently connected, any other device will be > > blocked after the daemon starts". > > I think the fact that usbguard (with the PresentDevicePolicy set to > `keep`) allows devices the user has explicitly configured to be > forbidden is a bug- I have filed > https://github.com/USBGuard/usbguard/issues/314 to address this. (I > think thats especially problematic since the user is not informed that > their rule is ignored). > I think when the `keep` policy honors the rules file it is safe to > change the default of PresentDevicePolicy to `keep`. >
Right, I see. I would argue this is not a bug but work as intended (the intent of the apply-policy settings was clearly an apply-rules more than anything). If this is the behaviour you really want, then generating the policy and leaving PresentDevicePolicy to apply-policy makes more sense. I'm ok with that option. > > > I've started https://wiki.debian.org/USBGuard. I'll keep editing this > > page based on our conversation here. > Thanks, I'll also add a REAME to the debian package. > > cheers, > Birger
