As far as I can tell, it uses the normal drivers for devices instead of a special one for WebUSB, so you need a working driver for it.
Conversation
which makes sense really, it would be pretty concerning if it started elevating itself and self-signing INFs
1
1
It also means it depends on installing the same fastboot udev rules as usual on Linux which annoys me. I had to add that back to grapheneos.org/install/web since I'd deleted it when I copied the CLI installation guide there expecting that it wasn't going to be needed.
2
1
it would be *much* more concerning if it had a SUID binary that can talk to udev.
1
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.
right, uaccess vs plugdev actually make a difference here!
1
Show replies
"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
Show replies