right, uaccess vs plugdev actually make a difference here!
Conversation
Quote Tweet
Replying to @DanielMicay @whitequark and @bmastenbrook
TAG+="uaccess" makes it so that if you're at a local session, you can use the device. The adbusers group in these udev rules is useless for most people. It's useful if you need it to work via a non-local session (SSH).
1
Quote Tweet
Replying to @DanielMicay @whitequark and @bmastenbrook
The purpose of systemd-logind (previously consolekit) is largely to deal with tracking remote vs. physical sessions and the active session to grant/revoke these kinds of privileges. And yet... I need to deal with it myself by opening some file as root in vim to use USB in 2020.
1
Look at `getfacl /dev/snd/controlC0` and you can see it in action. For that example, uaccess grants users with active physical sessions access (if you switch users, you lose it while in the background) and the audio group means you always have access to it.
1
1
That's generally how this works. The part that really annoys me is that they don't set uaccess on stuff like a serial device, fastboot / adb, hardware wallet, etc. The rules cover common cases but packages have to ship their own rules dealing with every USB device case-by-case.
1
1
There are people involved in this kind of decision making with no actual threat model or rational thinking about security paired with an anti-user attitude. If I can smash the device with a hammer or plug it into something else, just let me use it. It's not just USB either.
1
1
I at least claim to not be afflicted by either. permission dialogs are a barrier for our users! I want our devices to be usable! but I'm concerned about the "how could this possibly go wrong" approach as applied to a class of devices with historically less than zero security...
1
1
... I'm concerned about a kernel side interface that's not been treated with enough care, and I'm concerned that use cases where the physically logged in user does not own the machine are getting lost
maybe all of these are worth smashing? if so, let's call that out as a goal
2
1
but the fact that the WebUSB folks immediately yolo'd themselves into breaking the FIDO security model does not speak well of the amount of prior planning that's been put into changing the longstanding assumptions about what can access USB devices
ref:
1
1
It's already broken for a compromised device. When I use FIDO login with my Trezor Model T, it shows me the site identity on the touchscreen and I have to allow it there. The security key design is already broken if it relies on the OS / browser not being compromised.
I'm not really talking about WebUSB though. I'm talking about how Linux doesn't let me use devices as a user with physical. An application shouldn't be able to use a USB device without my consent, but I should be able to grant it the ability to do that.
1
1
as long as the consent mechanism is there, I'm 1000% behind this for all OSes. getting the system to handle this instead of having to write some kind of authenticated proxy for device traffic would be an enormous security win
1
1
Show replies
historically users are really really bad at comparing things on two different screens
IMO the FIDO model is broken in all sorts of ways, so this might just be an artifact of that
1
1
In general, I don't think an HSM without secure input and output can actually provide as much as people expect from them.
For example, a hardware wallet for Bitcoin with no display lets an attacker send a million dollars to themselves when you confirm buying a pizza with it.
2
1
1
Show replies
