Conversation

Replying to

and

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.

GitHub - M0Rf30/android-udev-rules: Android udev rules list aimed to be the most comprehensive on...

Android udev rules list aimed to be the most comprehensive on the net - GitHub - M0Rf30/android-udev-rules: Android udev rules list aimed to be the most comprehensive on the net

1

1

Replying to

and

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.

android-udev-rules/51-android.rules at main · M0Rf30/android-udev-rules

Android udev rules list aimed to be the most comprehensive on the net - android-udev-rules/51-android.rules at main · M0Rf30/android-udev-rules

1

2

Replying to

and

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

Replying to

and

are there any USB devices that would be unwise to expose to anyone in `plugdev`?

2

Brian Mastenbrook

Replying to

and

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

Replying to

and

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

Replying to

and

right, uaccess vs plugdev actually make a difference here!

1

Brian Mastenbrook

Replying to

and

ok, this is where I am dumb, what is uaccess

2

Replying to

and

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

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.

1

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.

4:32 AM · Jan 25, 2021Twitter Web App

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.

1

1

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.

1

1

Show replies