Just about everyone using Windows XP runs the operating system as administrator - or root, if you come from a UNIX background. Such is the case because Microsoft, in its infinite wisdom, figured it somehow made sense to give every user full access to the system, and to more or less completely ignore the intricate and advanced security systems in place in Windows NT and the NTFS file system. This kind of turned out to be a very bad idea, and allowed Microsoft and its 3rd party developers to become hopelessly sloppy; most Windows applications more or less assumed they were run by administrators. It also allowed malware full access to the system when executed. Cue User Account Control.User Account Control was introduced in Windows Vista as a means to forcefully wake up application developers and users. Even though the first user created on a Windows Vista system is still a member of the Administrators group, this user's privileges are severely limited due to the fact he or she receives not one, but two tokens. They share the first token with a normal, non-admin user: it contains all the basic privileges. The second token contains elevated privileges. This user's applications are started with the first, restricted token, while applications that are granted admin rights (clicking "yes" in the UAC dialog) will be started using the second, unrestricted token. Kenny Kerr explains it better than I do, by the way.
The point is that with UAC, normal users and administrators alike are made aware of any potential security threats; applications that mean harm have to explicitly receive elevated permissions by the user. Therefore, turning UAC off is generally a bad idea (especially since it also disables the sandbox Internet Explorer 7 runs in). I hate to break it to you, but security is annoying. I find it annoying to lock the doors of my house and car every night, and open them again the next morning - however, I still do it, because I don't want to have my gear nicked. Eventually, programmers will get used to UAC, and will cease making applications that assume admin privileges (and therefore, create a lot of UAC dialogs). This may take some time, but they'll get there.
Microsoft also prohibited applications that require elevated permissions from running when the user logs on. The reasons were explained on the UACBlog back in August 2006:
However, there are a few ways to get around this limitation. The first is using the Task Scheduler to launch the application in question. The second is to split the application in two parts; a system service running under the SYSTEM or LOCAL SERVICE accounts so that it has full system access, and a normal application that interacts with that service and directs it to do the things that required the admin privileges in the first place.
And that is exactly what the guys at NeoSmart Technologies did in order to get their application iReboot to run like they think it should. iReboot is a little program that lives in your system tray that allows you to select which operating system your computer should boot into upon the next reboot. It does this by modifying the boot entry that is marked as default in BOOT.INI (Windows XP) or the BCD (Windows Vista). Both actions obviously require elevated permissions. Before this change, iReboot on Vista had to be started manually, or you needed to resort to the Task Scheduler option.
From this, the guys at NeoSmart end up at the following conclusion:
That's a pretty bold conclusion - overly bold, if you ask me. The decision to block applications that need elevated permissions from running at logon was not a security decision, but a usability decision, as the quote from the UACBlog at the beginning of this item explains. On top of that, UAC does, in fact, act as a security barrier with iReboot. You see, installing the application obviously still requires elevated permissions to install its two parts - it has already passed UAC during installation. So, the issue here seems that Windows lacks a method of informing users a new system service is being installed.
I try to limit the amount of applications on my system that need to install system services in order to function properly, or that even just install unnecessary services without my consent (QuickTime and iTunes, for example). I regularly load services.msc and msconfig to disable services that come with applications.
Willingly relinquishing control over your bootloader to a system service that doesn't come straight from Microsoft seems utterly alien to me. Bootloader files should be properly protected and should not be easily accessible. What if a bug in iReboot's system service renders your BCD or BOOT.INI corrupted?
