If you download a mobile app, you get asked all kinds of things, like whether you want to allow location, access to the local network, file access, etc. (what things should the program be able to do and know). Desktop and server operating systems mostly don't have these because they were developed so long ago (and Micro$oft is lazy and incompetent).
There's higher resolution privilege approaches that aren't on/off but you'll typically see those in the form of manually configured user profiles and stuff. things the average desktop user just doesn't care for.
The best solution that's been proposed IMO is something called capability based security, which allows a hierarchy of trusted brokers to delegate very specific permissions for specific resources (files, hardware access, system calls) to applications. Rather than having the applications run as a "user" and inherit all the users permissions, the application is passed cryptographically secure "keys" representing a temporary permission to perform specific actions on a resource.
That's a big change to existing models though, a less dramatic solution would be applications running under an unprivileged user context then specifically requesting access to various features and files, like the Access Control List system Android layers on top of Linux ("do you want to allow this application to make phone calls etc.") or having multiple user accounts with varying privileges and applications requesting temporary permissions to run under the required user rather than having one big root account that does everything and everything needs access to.
The big problem with the root user is that for every privilege you choose to restrict to the root (or administrator), as soon as an application needs to perform one of those actions it must also get access to every single other interface protected by the root user account. Configuring network interfaces requires root access, but anything allowed to configure a network interface automatically is also allowed to read and write every single file on the system, including drivers, the kernel code and the boot structures.
How do you avoid the "root user" concept tho? What's the alternative?
If you download a mobile app, you get asked all kinds of things, like whether you want to allow location, access to the local network, file access, etc. (what things should the program be able to do and know). Desktop and server operating systems mostly don't have these because they were developed so long ago (and Micro$oft is lazy and incompetent).
There's higher resolution privilege approaches that aren't on/off but you'll typically see those in the form of manually configured user profiles and stuff. things the average desktop user just doesn't care for.
The best solution that's been proposed IMO is something called capability based security, which allows a hierarchy of trusted brokers to delegate very specific permissions for specific resources (files, hardware access, system calls) to applications. Rather than having the applications run as a "user" and inherit all the users permissions, the application is passed cryptographically secure "keys" representing a temporary permission to perform specific actions on a resource.
That's a big change to existing models though, a less dramatic solution would be applications running under an unprivileged user context then specifically requesting access to various features and files, like the Access Control List system Android layers on top of Linux ("do you want to allow this application to make phone calls etc.") or having multiple user accounts with varying privileges and applications requesting temporary permissions to run under the required user rather than having one big root account that does everything and everything needs access to.
The big problem with the root user is that for every privilege you choose to restrict to the root (or administrator), as soon as an application needs to perform one of those actions it must also get access to every single other interface protected by the root user account. Configuring network interfaces requires root access, but anything allowed to configure a network interface automatically is also allowed to read and write every single file on the system, including drivers, the kernel code and the boot structures.