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.
Conversation
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).
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
I see needing to use root for any normal usage of the computer as a serious design failure. And really, it's anything that can't work within an application sandbox via a case-by-case consent system. User needing to allow an app to access USB devices makes sense.
ok, I think we're in complete agreement about the goal. the idea that USB access is a capability that originates with physical access and is granted to specific sandboxes is what I want, basically
1
1
careful design is still needed here, so that the user understands the difference between "I want to grant this sandbox access to the contents of <SanDisk Ultra Fit>" and "I want to grant this sandbox access the ability to issue raw USB and SCSI commands to <SanDisk Ultra Fit>"
1