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:
Without blocking applications from prompting for elevation in the user’s logon path, both standard users and administrators would have to respond to a User Account Control dialog box on every log on. While this potentially becomes an annoyance for administrators, it is an unusable UI for standard users who cannot drive the UAC elevation prompt without having an administrator around to provide credentials. Furthermore, we advise users to be wary of prompts that appear without them taking an explicit action – and prompts generated at startup go against that advice.
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
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:
Perhaps most importantly though, is the fact that Windows Vista’s newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security. Any program that UAC blocks from starting up “for good security reasons” can be coded to work around these limitations with (relative) ease. The “architectural redesign” of Vista’s security framework isn’t so much a rebuilt system as much as it is a makeover, intended to give the false impression of a more secure OS.
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
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