Neosmart Technologies recently posted a diatribe about Windows Vista’s UAC subsystem, and how it basically forced them to rewrite their iReboot application. iReboot is an interesting Windows application which allows you to set the bootloader to load whichever OS you want on the next reboot, rather than waiting for the system to reboot, and quickly interrupting the bootloader to override it’s default selection. Thinking back to the days when I still dual-booted and the increasing popularity of the Intel-based Macintoshes, I can definitely see why this application has begun to catch on.

However, after reading this editorial by the author of iReboot, regarding the challenges he faced making the application work correctly on Vista. In short, he had to split the application into two parts: a System-level Service which does the modification of the Boot Loader, and a user-mode application which the user uses to send commands to the service. Seems pretty reasonable to me, and Unix systems have done this for decades. The Windows Kernel has always used a similar communication mechanism as well.

His basic argument is that the application must be installed as an Administrator, so therefore it should be able to start as an Administrator without any problems. However, Vista’s UAC wants to verify with the user every time the app starts up to verify that the application is allowed to do what it’s trying to do. Now, ignoring the annoyance factor of UAC, which Microsoft evidently did on purpose, it is perfectly reasonable for Vista to do this. What Mr. Al-Qudsi seems to completely fail to understand about Application Security, is that the Operating System decides who has what permissions on the user level not the application level. It is up to the user to, if necessary, elevate the permissions of an application to accomplish a system-level administration task.

If iReboot was allowed to elevate it’s privileges automatically, than any application ran by that user could elevate it’s privileges as well. In the comments, someone mentioned that perhaps a “RunElevated” registry key could be added, but that seems to me to be terribly prone to abuse. Some applications need to be installed with Admin Privileges but shouldn’t require those privileges to run, but with this registry key, ISVs could easily bypass the built-in security model in Vista.

Ultimately, it comes down to a security trade-off. By making the portion of the application which does elevated privelege attacks separate, it becomes easier to ensure that the application does what it is said to do, plus it is easier to test those code-paths and ensure proper behavior. It ensures that the inputs to the elevated code are better defined through an exposed interface, and encourages stronger design from the outset. It is a bit harder for the programmer, as their code now depends on Inter-Process Communication libraries and potential threading issues. At the end of the day, it reduces risk. it reduces the access of an unprivileged user to privileged code, it reduces the necessity for a user to have unnecessary access, and it better encapsulates the roles each part of the software plays.

As a former Administrator of a Windows 2003 and XP-based network, it was constantly frustrating for me to realize the number of tasks that my users struggled to complete because they simply had user permissions, how quite a few pieces of software would fail to run correctly due to the reduced permissions set of most users. In many ways, ISVs like Neosmart are responsible for the traditionally poor state of security on the Windows platform, due to their refusal to implement their software correctly, and their complaints regarding what they need to do for Vista compatibility.

Even in my current office, our helpdesk people struggle daily with legacy software that doesn’t work right (or at all) on Vista because the developers depended on bad behavior in XP and older OSes, and they’ve refused to correct their software in a timely manner. Vista isn’t going away. Windows 7 may be coming sooner than anyone expected, but it will build upon the Vista core, rather than stepping back to XP. There has been a paradigm shift at Microsoft, and this time it was definitely for the better. ISVs need to get on board, or prepare to made irrelevant.