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.
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.