set PresentDevicePolicy to allow by default

[muelli]

This is arguably making it more usable, because it prevents users from being locked out. With the user installing USBGuard through their package manager, the daemon is started as well. With the current default configuration the user is then locked out of their system without a way to configure the daemon.

This change attempts to make it more user friendly by not blocking existing devices by default. It is a compromise of security there as the attacker now needs to wait for a reboot, only. But I think we ought to err on the side of usability in this case.

[coveralls]

Coverage increased (+0.01%) to 57.348% when pulling b5fa894 on muelli:patch-1 into d5faec3 on USBGuard:master.

[muelli]

this change would probably prevent issues such as #268

[dkopecek]

Thanks for this suggestion.

I think such changes should be done downstream rather than in upstream. The change makes usbguard more user-friendly but less secure by default. The proper way to install and use usbguard is to generate a policy before the first start.

I think setting PresentDevicePolicy to allow by default just enables an attack scenario in which you somehow DoS the daemon to crash & restart and therefore allow devices which were connected before the crash (and not allowed). i.e. is allows an easy bypass of the policy if you know how to make the usbguard-daemon to restart.

What do you think about this reasoning? Should the defaults prefer user-friendliness or security?

[muelli]

The proper way to install and use usbguard is to generate a policy before the first start.

fair enough.
Obviously, the current way how it works leaves people locked out of their machines.
You may want to consider detecting whether the user has actively configured the software.
I don't think it's too smart to assume a static list of USB devices, though.

However. If you expect the user to actively configure USB Guard first, anyway, then you can also opt for the default configuration that works rather than annoys users.

I'm wondering though. If a device has indeed blacklisted by the user, would such a rule not have precedence?
One option to prevent the scenario you've outlined is to encode the state as transient files in, say, /run/user/usb/hash/state with the file containing either "allowed" or "blocked" or something. The daemon can then check those files upon starting and take appropriate steps to return to the state just before crashing.

[dkopecek]

The proper way to install and use usbguard is to generate a policy before the first start.

fair enough.
Obviously, the current way how it works leaves people locked out of their machines.
You may want to consider detecting whether the user has actively configured the software.
I don't think it's too smart to assume a static list of USB devices, though.

However. If you expect the user to actively configure USB Guard first, anyway, then you can also opt for the default configuration that works rather than annoys users.

I'm wondering though. If a device has indeed blacklisted by the user, would such a rule not have precedence?
One option to prevent the scenario you've outlined is to encode the state as transient files in, say, /run/user/usb/hash/state with the file containing either "allowed" or "blocked" or something. The daemon can then check those files upon starting and take appropriate steps to return to the state just before crashing.

This is an interesting idea, let's create a dedicated RFE issue for this and brainstorm there. I'm going to close this PR as the default won't be changed upstream for now.

[anarcat]

i am not sure DOS on the usbguard daemon is much of a concern for this level, no? what's the actual attack scenario here?