I don't think Windows permissions are that complicated, and certainly covers the problem space of actual companies better than unix. The problem is that the original design was somehow opinionated and didn't match what home users were doing.

To oversimplify:

- there's the kernel, which can do anything

- there SYSTEM, which is is kind of like "root" in unix, but only used by services (you can't log in as SYSTEM)

- there are user accounts with Administrator rights, which can do "anything" (can be slightly limited by the above two)

- there are user accounts without Admin rights, kind of like normal user accounts in unix.

There are also more specialized Admin privileges, rights for everything are actually controlled by Access Control Lists and tokens, and your accounts and their rights might exist locally or domain-wide (centrally managed on some server), but unless you're a company you don't care about that.

The problems you describe are mostly due to three things:

- Home users got into the habit of only using one user account with admin credentials. It's convenient, but effectively running everything as root. That's why we now have UAC (that prompt when you try to do admin stuff with an Admin account), and the transition to UAC was pretty rough.

- Some software actually wants some protection from the user (antivirus has to protect itself from processes started by the user, anti-cheat has to protect itself from the user, etc.) Because home users use Admin accounts for everything, the only escape upwards in the hierarchy is into the SYSTEM account or into the kernel, with the latter being much more secure, but much worse if you do it wrong

- In large corporations obviously only IT has Admin accounts. That's how the system is supposed to work. People still want to install software without calling IT, so some software installs in the user folder (in %APPDATA%). That's no different from installing in ~/bin in unix.

The last two points are equally bad in linux, you just don't come across them as often because nobody does anti-cheat and runtime anti-virus on linux, and most linux systems are ultimately used and administrated by the same person

> - there are user accounts with Administrator rights, which can do "anything" (can be slightly limited by the above two)

Not technically. Windows permissions follow a "capability" model more than a "user" model. In the Linux user model a user account is always "just one thing". In a "capability" model the user may request different capabilities at different times (based on different needs).

Even in the bad pre-UAC days users didn't have Administrator rights "at all times" in the sense of an Admin account (or group) in the Unix/Posix model, they'd request the capabilities as they needed them and the system would grant them as it saw fit, which was usually just automatic and invisible. The tokens for admin and non-admin stuff were "always" different in Windows. UAC just finally changed it from an "auto-grant" to a "user consents to the grant". UAC wasn't bolted on to the security model of Windows NT, it intercepted token flows that already existed and removed the "automatic" nature of them. (That's why the UAC transition hurt so much at first, especially in Vista, not that it was "bolted" on, but that a lot of software had been built around presumptions about these "automatic" token flows and assumed they were cheap/easy so over-requested them rather than requesting them as rarely or as specifically as truly necessary.)

> Home users got into the habit of only using one user account with admin credentials. It's convenient, but effectively running everything as root.

Not in the Linux sense, no. A home user account isn't "effectively running everything as root". UAC is like sudo in that it acquires a separate user token for subsequent actions. Details about the account may be similar (because of the capability model, the "account" is the same, but the capabilities differ), but they are "distinct" accounts in the Posix reasoning of name+capability.

Large companies that disable UAC and require separate "Admin" accounts are over-reacting/over-correcting, often because they are expecting the Linux/Posix model or because their tools were. UAC is a sudo-like tool: the user tokens are very different on the other side of the UAC fence. Requiring a "physically" separate account is security theater and not very different from just changing UAC from Yes/No flows to "Require Password" flows (unless your auditing tools are bad at their jobs and coalesce tokens with different capabilities based on things like username due to presumptions from Posix systems). It's silly to manage twice as many accounts when you can just make UAC stricter and require passwords. (And also Microsoft's several decades of research show that "Require Password" flows are themselves security theater, people don't actually think longer about UAC prompts if they have to type their password in more often, it just trains them to type their password in more often, which makes it easier to phish their passwords.)

> I don't understand how Windows still works off of you receiving packages at your door and the only way to verify its safety is guess that the timing of your package syncs up with what you ordered and the packaging looks like what you got, and to have hope that the place that packed it wasn't malicious. While nearly all programs do include bombs (unwanted tracking / malware / bad design), usually they're just fairly harmless firecrackers. The only way to open your package up is to put it on the flammable gas pipe in the middle of the house (a left over design from earlier versions of the house) which has a very heavy flaming chainsaw attached to a 1 inch chain.

This is exactly what the "Signed by Windows" MSI feature is for. Of course it is also a cash-in with a prohibitively lengthy and expensive process for publishers though (IMHO)