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.
Conversation
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
"anything which runs as my user can write out a suid root file to disk and run it" is... breaking a lot of longstanding assumptions. that might be /fine/ but it deserves, like, a paper at least explaining why?
1
2
Sudo with a password is security theater anyway. Anything with access as your user can capture the password as you enter it. There are so many ways doing it. If you actually wanted to keep root separate you'd need to do something like only logging into it from a virtual console.
1
1
1
that too but I see it more simply, pick whatever you want enabled by having root, well you can do something at least as bad with just my user account
2
2
sure, and as a single user desktop that makes sense for most people. (on servers I replace sudo with two separate sshd instances, one running as my user account and the other bound to localhost running as root and accepting root login via agent forwarding)
3
1
Basically, if you want to secure against that for real, you need to use verified boot and authenticated encryption with per-user encryption keys for everything not covered by verified boot. Otherwise, the user can take out the drive and plug it into another computer to modify it.
yep. sure, I use FDE. anyone serious with physical access can just repack initrd