Conversation

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).

Daniel Micay

@DanielMicay

Jan 25, 2021

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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.

Replying to

and

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...

Replying to

and

... 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

Replying to

and

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:

yubico.com

WebUSB in Google Chrome and Responsible Disclosure

In 2018, Yubico worked with Google to help address security vulnerability issues for WebUSB in Google Chrome that affected FIDO U2F authenticators

Replying to

and

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.