Re: No magic bullet
> and Windows, starting as a single user system, has found it difficult to build security in
The current strain of Windows has nothing to do with the single-user 9x strain. Windows NT was a clean-room re-implementation of Windows, with security and authentication built in from the start in an *extensible* model that was prepared for future enhancements. Windows 2000, XP, Vista, 7, 8 and 10 are all based on the same security model.
And it solves all of your complains about Unix.
> First, instead of accessing storage on their own user processes should go through a back-end with specific permissions
Windows (and Linux/Unix) already goes through a back-end (known as syscalls) when accessing resources. This is an ideal place to enforce security restrictions. Linux allows LSMs to intercept syscalls and perform extra access checks. Windows tokens are far more advanced than the Unix model and has catered for this type of security access checks from the start.
However, only Unix/Linux came up with the stupid idea of creating a deliberate hole in the model when they chose to elevate a single user (uid 0) to "god", by creating bypass code in every syscall to just let root through. There is no similar hole in Windows: All users - including administrators - are just users and must pass through the same security checks. Admins are only admins because of the permissions *granted* to the accounts.
> Secondly, introduce a concept of application permissions that sits alongside user permissions
Windows AppContainers (not to be confused with docker containers) was introduced in Windows 8 - and leverages the same token based security that is in Windows since the first Windows/NT. When the token contains a special SID, the process is restricted *beyond* what the user can do, i.e. *both* the user *and* the application must have explicitly granted access to a resource for the process to be able to access it.
https://msdn.microsoft.com/en-us/library/windows/desktop/mt595898(v=vs.85).aspx
> Thirdly, and this is where something like Apple's idea comes in, the kernel would lock root out from changing such storage on its own account; it would need to be authorised by a specific user, such as odf-admin for instance, to de-allocate odf storage.
And that is where is Unix model fails. Big time. This is yet another SUID/setuid fiasco. A security model where you gain *extra* privileges from the process that you run is a deliberate (but *stupid*) security hole.
What you want is to get rid of the "god" account and use discretionary privileges instead. The user's permissions should be an *upper bound*. If he/she needs to perform an action that requires permissions he/she does not hold, he/she must interact with a service instead. The service can perform authorization checks, but under NO circumstance should the process run within the requesting user's context. This latter part is why vulnerabilities such as shellshoch were so devastating.
Biting the hand that feeds IT
