Until Vista and Win 7, it was effectively impossible to run a Windows NT system as anything but Administrator. To the point that other than locked-down corporate sites where an IT Professional was required to install the Corporate Approved version of any software you need to do your job, I never knew anyone running XP (or 2k, or for that matter NT 3.x) who in a day-to-day fashion used a Standard user account.
Of course, I don't know of any Linux distribution that doesn't require root to install system wide software either. Kind of negates your point there...
In contrast, an "Administrator" account on OS X was in reality a limited user account, just with some system-level privileges like being able to install apps that other people could run. A "Standard" user account was far more usable on OS X than the equivalent on Windows, because "Standard" users could install software into their user sandbox, etc. Still, most people I know run OS X as Administrator.
You could do the same as far back as Windows NT 3.1 in 1993. The fact that most software vendors wrote their applications for the non-secure DOS based versions of Windows is moot, that is not a problem of the OS's security model, it is a problem of the Application. This is not "Unix security" being better, it's "Software vendors for Windows" being dumber.
It's no different than if instead of writing my preferences to $HOME/.myapp/ I'd write a software that required writing everything to /usr/share/myapp/username/. That would require root in any decent Unix installation, or it would require me to set permissions on that folder to 775 and make all users of myapp part of the owning group. Or I could just go the lazy route, make the binary 4755 and set mount opts to suid on the filesystem where this binary resides... (ugh...).
This is no different on Windows NT based architectures. If you were so inclined, with tools like Filemon and Regmon, you could granularly set permissions in a way to install these misbehaving software so that they would work for regular users.
I know I did many times in a past life (back when I was sort of forced to do Windows systems administration... ugh... Windows NT 4.0 Terminal Server edition... what a wreck...).
Let's face it, Windows NT and Unix systems have very similar security models (in fact, Windows NT has superior ACL support out of the box, akin to Novell's close to perfect ACLs, Unix is far more limited with it's read/write/execute permission scheme, even with Posix ACLs in place). It's the hoops that software vendors outside the control of Microsoft made you go through that forced lazy users to run as Administrator all the time and gave Microsoft such headaches.
As far back as I remember (when I did some Windows systems programming), Microsoft was already advising to use the user's home folder/the user's registry hive for preferences and to never write to system locations.
The real differenc, though, is that an NT Administrator was really equivalent to the Unix root account. An OS X Administrator was a Unix non-root user with 'admin' group access. You could not start up the UI as the 'root' user (and the 'root' account was disabled by default).
Actually, the Administrator account (much less a standard user in the Administrators group) is not a root level account at all.
Notice how a root account on Unix can do everything, just by virtue of its 0 uid. It can write/delete/read files from filesystems it does not even have permissions on. It can kill any system process, no matter the owner.
Administrator on Windows NT is far more limited. Don't ever break your ACLs or don't try to kill processes owned by "System". SysInternals provided tools that let you do it, but Microsoft did not.
All that having been said, UAC has really evened the bar for Windows Vista and 7 (moreso in 7 after the usability tweaks Microsoft put in to stop people from disabling it). I see no functional security difference between the OS X authorization scheme and the Windows UAC scheme.
UAC is simply a gui front-end to the runas command. Heck, shift-right-click already had the "Run As" option. It's a glorified sudo. It uses RDP (since Vista, user sessions are really local RDP sessions) to prevent being able to "fake it", by showing up on the "console" session while the user's display resides on a RDP session.
There, you did it, you made me go on a defensive rant for Microsoft. I hate you now.
My response, why bother worrying about this when the attacker can do the same thing via shellcode generated in the background by exploiting a running process so the the user is unaware that code is being executed on the system
Because this required no particular exploit or vulnerability. A simple Javascript auto-download and Safari auto-opening an archive and running code.
Why bother, you're not "getting it". The only reason the user is aware of MACDefender is because it runs a GUI based installer. If the executable had had 0 GUI code and just run stuff in the background, you would have never known until you couldn't find your files or some chinese guy was buying goods with your CC info, fished right out of your "Bank stuff.xls" file.
That's the thing, infecting a computer at the system level is fine if you want to build a DoS botnet or something (and even then, you don't really need privilege escalation for that, just set login items for the current user, and run off a non-privilege port, root privileges are not required for ICMP access, only raw sockets).
These days, malware authors and users are much more interested in your data than your system. That's where the money is. Identity theft, phishing, they mean big bucks.
