it would be *much* more concerning if it had a SUID binary that can talk to udev.
Conversation
Yeah, but originally I expected that WebUSB was a special thing that would use a generic WebUSB driver. I didn't realize it was just normal USB.
2
1
For common USB devices, the udev rules already exist. It's actually quite annoying that it's not more generic. I don't really understand the point of someone having to maintain github.com/M0Rf30/android in order to authorize local users (users physically at a session) to use it.
1
1
The only reason the Debian package with the udev rules works for current Pixels despite being so out-of-date is that they've kept using the same ids from Nexus devices:
github.com/M0Rf30/android
It wouldn't work well for most other brands of devices.
1
2
Needing to teach people to put a file in /etc/udev/rules.d/ is a pretty bad usability issue. It really doesn't make any sense. Needing to authorize a sandboxed app to use a device actually makes sense. The user themselves should be able to use local USB devices... sigh.
1
4
are there any USB devices that would be unwise to expose to anyone in `plugdev`?
2
this is a question that deserves a substantial amount of thought and analysis, but I can think of one obvious example immediately: the usb device that the root filesystem is mounted from
3
2
It might as well be accessible to a user with *physical access* though (uaccess). They can take a hammer and smash it and if the OS doesn't have verified boot, they can modify it by plugging it into something else. It's basically just security theater to not have global uaccess.
2
1
right, uaccess vs plugdev actually make a difference here!
1
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).
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
Show replies