Back in August of 2007, NeoSmart Technologies released iReboot 1.0 – a tiny application that sits quietly and unobtrusively in the taskbar and is used to select which OS you’d like to reboot into.
iReboot isn’t by any means a major application, but it’s gathered a pretty strong following over the months, mostly by people interested in boosting productivity (or increasing laziness) to the max. But there was one flaw in iReboot that made all the hard work we put into making it as unobtrusive and minimalistic as possible almost meaningless: if you had UAC enabled, iReboot will not run automatically at startup, no matter what you do.
This behavior comes as a result of the architecture that Microsoft used to secure Windows Vista, which doesn’t allow for applications requiring admin approval to run at startup. It doesn’t matter what your application does or if you absolutely trust it beyond the shadow of the doubt, Windows Vista simply won’t let an application that runs in elevated privileges mode to launch at startup – end of story.
Users of iReboot were quick to point out that this is a major drawback that made it almost useless – after all, it’s far less productive to have to manually run an application when you want to reboot than it is to wait for that startup screen to appear and select the OS you want. So we set about finding a solution.
We’ve just released iReboot 1.1, a UAC-free implementation that doesn’t require admin approval, elevation, etc. past the initial installation. And, yes, it does run automatically at startup too!
The Gory Details (feel free to skip below to the download links!)
In order for iReboot to be of any use, we had to get around Microsoft’s UAC limitations. For iReboot, it was of the absolute importance that it run at startup, and that it be allowed system access from normal user accounts. On Windows XP – where everyone runs as an Administrator and there are no annoying UAC prompts – it was a non-issue. But on Windows Vista, the new architectural requirements for running applications in elevated privilege modes made it near impossible.
While digging around for possible solutions, it became clear that the only possible fix would be to split iReboot into two parts. One would run in the background as a service, running under the SYSTEM or LOCAL SERVICE accounts and having privileged access to the OS without requiring admin approval or UAC elevation, and with the second half running as an unprivileged userspace client program which interacts with the service backend to get stuff done.
The resulting application has an installer – which requires admin privileges, of course – which installs and launches the background service. The background service has full permission to do what we need to get operating system XXXX to be the default option for the next boot, but – in line with the Windows Service Model – cannot be interacted with by end users.
The installer also adds a normal UI application which sits in the taskbar (from where end-users may interact with and use iReboot) and communicates with the backend service via a custom API which must not require the execution of any privileged code. The service can do whatever it wants (well, whatever we want it to do, but lets not get picky here!), but the client program must only perform actions which normal, unprivileged users have permission to execute.
By using a standard inter-process communication API we avoided the need for any special actions on behalf of the client application, effectively separating logic (residing and executing on the backend service, free from the many limitations of UAC) and presentation/design (the client application, bound to obey UAC’s every wish).
The Bottom Line
Anyone running Windows XP or Windows Vista – with or without UAC and/or admin approval mode enabled – can now run iReboot at startup and use it to boot into whatever OS they like (in conjunction with EasyBCD, of course!).
But getting this far wasn’t easy. With Windows Vista, what should have been 100 lines of code maximum ended up being a dozen times longer, split across two different processes, and requiring way too much man-hours to write the most minimalist and to-the-point piece of software we’ve released to date.
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.
With the current Windows Vista security models, Microsoft can claim that Vista blocks system-modification tools from running at startup; but the truth is, there are still many ways to get them to run. At the end of day, our experience with iReboot and Vista’s security implementations brings us to the sad conclusion that with Windows Vista, Microsoft has made ISVs’ jobs more complicated without actually providing any any further protection for end users from malware authors – which certainly isn’t the best way of going about this task.
Anyway, the fruits of our efforts:
Download iReboot 1.1 (248 KiB)
Harry, good points. However, using UAC to aggravate users so that developers start caring is hardly the way to go about it. And worse, there’s little security benefit to be gained from this until Administrator is no longer the default, as you also point out.
Instead, the OS should create a “program account” when installing applications (like is often used with unix services). Default to admin-privileges on x86 and non-elevated on x64 with options for installers to request additional privileges. Such a design would be in line with x64 introducing additional security features (e.g. PatchGuard) while x86 focuses on backwards compatibility.
Alas, Vista has shipped and UAC will remain with us.. I’m just amazed that this was the best idea Microsoft could come up with.
Morten – Have you actually ever used Vista? Non-Admin is the default. And even if you run as Administrator you run (by default) in a non-privileged mode and, when you perform a privileged operation, get a dialog reminding you that youre running one and you have to click a button to continue. So even if you run as Admin you get some reminder of elevated operations. A normal user also has to enter Admin credentials at this point.
Morten:
I’m not sure how a “program account” could fit in with the current model. Certainly it would be an even more extreme change than UAC – although perhaps I misunderstand what you’re imagining. (Personally, I’d like to see even more radical changes; but my ideas would require a brand new OS and significant redesign work for application developers. Not really something that could fly for the foreseeable future.)
It’s true that there’s little security benefit to UAC in the short term, but there is a non-security benefit for at least some of us: more programs that work for people who don’t log in as administrator.
On the other hand, I guess I’m biased; I get the benefit without the cost, since we still run Windows XP almost exclusively.
Now that all the pissing and moaning has stopped, I was just wondering: how many of those with opinions about network/computer/system security actually have the schooling and training that accompany the acquisition of a Computer Science degree? I suspect that those who were in favor of the dual-component implementation actually have this training because the ‘separation of privilege’ paradigm is a core requirement for well-implemented security models.
I will not spend the time to detail the aforementioned security issues, but suffice to say, that if the only difficulty bothering the implementers is the amount of work involved or some other annoyance associated with writing software, maybe they should learn to touch-type… it will facilitate their jobs as programmers.
And although I loath most everything M$, they actually HAVE made VISTA more secure (not TOTALLY secure) than any of their previous products.
To Lew:
For your reference, since you asked, I have a BS in Comp Sci / Mathematics (from a fairly good college), and over 10 years of experience.
And for those people not familiar with Vista:
The reason you need a dual-component implementation is that anything which interacts with the shell (which is required to display a tray icon) cannot be running in a privileged context. If you want a tray icon context menu command or click operation to perform an operation which requires a privileged context, it must logically make a LPC/RPC call to another elevated process which can. Pre-Vista, services could interact with the user window session under certain conditions (Interact with Desktop), so the separation wasn’t always necessary.
Hope that explanation helps.
Larry, I’m running Vista with an Administrator account as I strongly prefer a long and complex password (which just isn’t viable with a regular user account and UAC). Force people to re-enter the password often enough and they’ll pick something easy, count on it.
Harry, “program accounts” is just regular system accounts except that they cannot be used for interactive logins by users. This allows programs to run with tailored permissions.
Lew, that’s just arrogance speaking. Don’t presume that people without formal CS training can’t comprehend complicated security issues. Separation of concerns is good (QMail is a prime example of this), but there are many other concerns for application developers: performance, time-to-market (developer productivity), maintenance complexity, etc. If you want developers to write secure programs, just make it cost-effective to do so. Or at least reasonably cost-effective.
Larry, the default account in Windows Vista is an administrator – but like you mention, it too runs in “Administrator Approval Mode” w/ UAC enabled.
Lew, I will not bother to answer your question. Just re-read the article and the comments.
Richard Steven Hack:
That’s exactly what iReboot 1.0 used to do. Except that Windows Vista wouldn’t require an application that asked for the admin password to run at startup, hence the need for iReboot 1.1 to automate the whole thing.
Just wanted to say thanks for iReboot, it’s a real awesome utility!
Now I can just restart my PC via iReboot, go take a shower, come back and find the right OS booted 🙂
This may be of interest to those following this thread:
http://blogs.msdn.com/crispincowan/archive/2008/04/28/uac-desert-topping-or-floor-wax.aspx
Guys and girls. We are here to discuss iReboot and not Microsoft Vista. No one has any doubts anymore that Vista is a failed OS which is just window dressing of XP. The usefulness can only be gauged by those selling new compatible software and hardware at the users expense since said users are not getting anything of value by being forced to buy a new system with a new OS instead of the good old OS. When I say being forced, I mean like buy a new SONY VAIO with Vista and install XP on it, your XP update for hardware will stay at 0 all the time. Microsoft does not want you to find any hardware updates for the spanking new vista compatible hardware to be used with XP or else every one who knows how will install XP and keep using their own programs that they have already paid for. Why should I be forced to buy the same programs over and over again or upgrade them while they are not doing anything new or that I need? How many USD100 are the changes worth to the general public between Office Pro for win3.1 and office 2007? Zilch. Some legislation is required and now that Obama is in the house maybe human beings can see some action that is of service to humanity instead of narrow minded ($$$) vested corporate interests.
Did I mention that this was about iReboot and not Microsoft? Well let’s get on with it then.
S.
What a childish rant. Is anyone in your operation over 20 years old?