Gadgets are controlled by system software vendors, not owners
📅 2024-10-17 📄 source
Thoughts about conflict between software security and user ableness, attempts to generalize and formalize, find possible compromise
Modern mobile operating systems treat device owner not as person controlling the device. Software is partitioned into "system" and "apps", all of them are immutable and can only be changed via update mechanisms, which replace previous immutable versions with new ones, fetched from "verified" external source. User is limited to interaction with device to apps, which have very limited permissions. Of course this is done to solve certain problems which reliability- and security-conscious user normally should want to be solved:
- software integrity: it is only possible to guarantee correct and secure operation of the software if it is in some "known/valid/verified/trusted" state. However, "Android-like" partitioning of the software into enormous immutable units makes it extremely hard to modify software. Basically, for any change in system, user has to set up enormous development env on other device, find out where in the enormous source tree consisting of numerous projects is something they want to change, run full build... And start mantaining their own fork if they want updates with their change
- I believe that with NixOS approach it is possible to achieve integrity while retaining possibility to relatively easily modify software; basically, NixOS partitions software into smallest "immutable units", which correspond to individual upstream projects like libs, progs and config files which system and apps consist of (like packages in oldschool Linux distros), it allows to have "comprehendable recipe" for system customizations and apply it on running system, building new instances of only those immutable units which are affected by described customizations
- protection from possibly malicious apps: apps are not trusted both by user and by providers of other apps, and are executed with minimal permissions. However, "minimal permissions" here actually means not "minimal for doing what user needs the software to do", but "minimal for what platform developers decided user might need apps to do". Apps are seen as agents of will of their providers, not of the user, which is also reflected by the fact that Android reuses ancient "Unix user" thing to identify not users, but apps, each installed app getting its uid with which its processes are executed. Of course there are "extra permissions" which apps can request and be granted, but there's always something which is practical to do but not possible to do without bypassing sandboxing, that's why Unix has "root" which is actually a tool for bypassing system security. Android sandboxing with all possible "extra permissions" leaves apps unable to do things as important for power user as reading network routing table, and rooting is seen as terrible sin by Android security community, primarily because it makes possible to break aforementioned integrity: once software has root, it can make changes to anything incl. cryptographic stuff so that changed software can run without triggering integrity check failure; the idea that user might want exactly this, specific local program which they trust to produce new trusted software on the device itself, possibly replacing older software, is rejected
- one of arguments against possibility of giving root permissions to apps is that having any UI to allow root would mean that shell can get root, and shell is a huge attack surface. However shell anyway has access to all sensitive information which user ever sees, and it should possible to split shell into "minimal part with UX for privilege elevation requests and minimal attack surface" and "full UX part" running on top of first one
- funnily enough, Android sandboxing doesn't even have true filesystem access isolation. Apps can create files in "user storage" even without storage access permission, enumerate and access any files created by them; enumeration exposes subset of directory hierarchy over which contains accessible files; files are accessible if they are owned by same uid which app processes are running with. Yes, this means Chrome can enumerate and access all files ever downloaded via it, incl. renamed/moved, check file:///sdcard .
Return to index