It's security's dirty little secret: Not having your users logged in as root or administrator will not stop malware.
[ RogerGrimes's column is now a blog! Get the latest IT security news from the Security Adviser blog. ]
There is a huge public security thrust to ensure that users are not constantly logged on with highly privileged access. In Microsoft Windows, this means not being logged in as a member of the administrators group or any of the other 17 groups with admin-like privileges (for example, Power Users). In Unix/Linux/BSD, this means not being logged in as root or bin or whatever else is close. In the AS/400, it means not being logged in as Qsysop or Qsecofr. For mainframes, it might mean superuser, terminal 0, or another user label indicating special privileges.
Unfortunately, the concept of least privilege is more a popular mantra than a rule in most environments. This is especially true at home, but it's nearly as bad at work. If you want to find someone logged in as administrator or root all the time, point your finger in the general direction of network security folks: "Do as I say, not as I do."
Microsoft is trying to encourage users and developers to go least privilege by introducing UAC (User Account Control) in Windows Vista, and the Unix/Linux/BSD folks have being trying for a decade longer with Switch User (SU).
The problem is that even if no one ever logged in as a superuser, it wouldn't make a dent in the ability of malware writers to do bad things to us and our computers.
It would stop a lot of the current malware, but only because they are designed (like a lot of today's legitimate software) to expect the user running it to be logged on as privileged. And in most cases, this is a good assumption. Most users are logged in using privileged accounts, but malware doesn't need privileged access to do bad things.
Even today, there are hundreds of malware programs that can do all the nasty things they want: modify your computer, steal your identity, whatever, without ever needing admin or root access.
Forget for the moment remote buffer overflows, social engineering, phishing, and all the other sorts of maliciousness that don't care about your logon credentials; malware doesn't need to modify your system files to cause problems.
It's always been a mystery to me why Windows malware tries so hard to modify files or place itself in the System32 directory. Most people say it's because the malware wants to modify the Windows OS, and that's true. But the System32 directory location isn't needed. I've been keeping a table of all the ways and places that Windows malware can locate itself to cause damage, and I have more than 130 entries. My Linux/Unix/BSD list is much smaller, but contains a few dozen locations. Many of the listings on both documents do not require admin or root access to manipulate.
For example, most Windows malware modifies the HKey\Local_Machine\Software\Microsoft\Windows\Run registry key, but I have dozens of other keys that can be modified to launch just as easily. For instance, malware can use the user's own registry profile keys instead. Users always have Full Control to their own profile's auto-run registry keys, and they are checked (and the listed programs launched) by the computer after executing code in the machine's startup areas.