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)
Uhh… I’m running an admin application on startup automatically all the time, there’s no need to create a service or anything.
Just use the Task Scheduler to start the application, Trigger=At log on; And select “Run with highest privileges”.
Daniel, if you’re using the task scheduler or a service it’s the same concept, isn’t it?
After all, the task scheduler itself is a service – if I’m not mistaken. But even if it isn’t, I agree with the article – having to resort to hacks such as background services or task schedulers is BS.
Because that’s what it is – either way, they’re just hacks to get around a broken security architecture! 🙁
> With the current Windows Vista security models, Microsoft can claim that Vista blocks system-modification tools from running at startup.
Where did Microsoft make that claim?
The problem simply is that the old registry keys for autostart have no way of specifying whether the started program should be elevated. Automatically (silently) elevating all autostart programs is a bad idea (non-elevated code can add autostart programs), and showing an elevation prompt pop up after every login is also a bad idea (I need to confirm a UAC prompt to login?).
So Microsoft ended up with that “autostart program was blocked” solution. It’s not a good idea, but it’s less bad than the alternatives.
But there was no intention of blocking programs from starting silently elevated, provided they are registered for autostart somewhere were only admins have access and where elevation can be explicitly controlled (because silently elevating just because some program says so is a bad idea). This is not possible with the Run registry key, but it’s possible with the task scheduler.
Sure, the task scheduler is a service, but the tasks it starts run in the user’s session, so they can display UI. There’s no need to write a custom service and use inter-process communication between a non-elevated UI and a service.
Daniel, in the time it took me to read your last reply I could already imagine more than one solution to the conflicts you detailed far more elegant than blocking all apps that require elevation.
The very simplest of these follows the age-old Windows model: when everything else fails, add a new registry key.
The registry already has Run and RunOnce. How about adding a RunElevated?
At any rate, none of this makes much sense. A program can’t add itself to HKLM\* without admin approval anyway.
There are plenty options out there better than any of this; it’s not really doing anyone any favors defending Vista’s obviously-flawed architectural design regarding “security best practices.”
HKLM\…\Run and HKCU\…\Run both are expected to start programs without elevation.
> add a new registry key.
You still need to block elevated apps using the old registry key.
So what’s the advantage of yet another registry key?
Remember that the task scheduler needs to be able to start elevated programs anyway, and it can already start programs using different user accounts since Windows NT.
Why a new registry key for elevation, but not for, say, tasks that should only run on AC power? Do you want to create a key for every possible feature combination of task scheduler?
Vista has a perfectly good solution for starting programs at all kinds of time with all kinds of settings: the task scheduler.
What you are proposing is to add complexity to offer another solution in addition to the task scheduler. Where’s the benefit in that?
If you introduce a RunElevated key, setup programs have to be changed anyway; so why shouldn’t they just add an entry to the task scheduler instead?
It’s not like the task scheduler is some black magic; there’s a documented API to add and remove tasks.
Is it Easy or Not Easy? It’s hard to tell the way this post has been written. Look how your started the ?bottom line?.
First you say it ?wasn’t easy?, citing additional code needed, more man hours, and extra processes and design modifications.
Then you reverse this on the next paragraph saying that UAC is ?easy to code around? and can be bypassed with ?relative ease?. Hello? Don’t these two sides conflict with each other? Which side is the truth? Which one is an exaggeration? Sloppy journalism.
p0wnd
Well your claim that the security model is inherently broken falls flat when you say this: “The resulting application has an installer – which requires admin privileges, of course – which installs and launches the background service.” Not being able to install or run potentially system breaking software without the user’s permission is I think the main windows flaw Microsoft was trying to fix. How UAC works etc, and all of the difficulties it causes for developers may not be handled in the best way of course. But your implication that vista is NOT more secure than XP is invalid. There will always be ways of breaking security, but from what I read in the article, it seems like you are more getting around design flaws, and not actually breaking security at all. I won’t be turning off UAC until I read a real article about the “ease” at which it is bypassed. Although I suspect to read such an article someday 🙂
But yes, boo on those design flaws!
Also, thanks for taking the time to make this work. Many of us are stuck with Vista and the program is very useful.
UAC is working exactly as it was intended. It’s designed to force Windows programmers to write secure programs. You’d have to do the exact same thing in Linux or BSD or any other operating system.
By making a service that uses elevated privileges, you’ve isolated the part of your program that requires elevated privileges. The GUI itself should now run with non-administrative privileges which means that your program is now only using elevated privileges when it needs to as opposed to all the time.
Unfortunately it’s quite apparent that you don’t understand that this is precisely how the security model is supposed to work. The whole point is separation of concerns: you have isolated the privileged portion of your application in a separate process, and the installation thereof requires manual user intervention. If this doesn’t make sense to you, I suggest that you take a look at how privileged operations have been performed in Unix for the past, say, thirty years.
The author must have some experience due to the simple fact he can write an application…I cannot write an application. But I think this is more a bitch session, more than anything else. The simple fact of the matter is the “installer” requires elevated permissions….end of point….you DID have to agree to UAC to get the program to run….anything else is Bullshit. To blame this on UAC failing is retarded in itself. If you run a script on a Linux box that you SUDO’ed (run as root) and it deletes the kernel. Is that the Linux boxes fault, or did you give the computer permission to do so. When you can write this application to run as admin without UAC being needed (and that means the installer as well) then you can call UAC broken.
1) Not everybody runs as and Administrator. There are people that are savvy about their computers AND their security – i.e. not running as Administrators and, gasp, possibly even using dual-boot.
2) If you make application that simply assumes that everybody runs as and Administrator and cry foul when suddenly your favorite OS provider comes to senses and makes you stop doing that, then you’re simply a bad programmer. Bad, bad programmer.
3) Wow… what a concept: you make a privileged system component (device driver, service, daemon, …) which is then accessed by unprivileged (userland) interfaces. If you worked around anything, it was basically just your own ignorance. Why do you blame some security put in place to prevent them from making the stupidity in the first place.
4) If you think you’re high-tech, then you should look around. UNIX had been doing the same since at least ’90s, after suddenly realizing that SUID root isn’t always a good thing.
5) Maybe you should find something else to do. If you think tested and accepted ways of doing critical system operations (as *NIX systems have been doing for decades) are “security flaws” and you think that you have actually managed to “break UAC”. If you seriously think that, then you belong in the GRC league, not the major league. If you complain about the code complexity, then you should be aware that you were simply ignoring the facts of system programming under any operating system that knows about that “multiuser thingy”. No you’re crying foul, because your own ignorance came back and bit you where it hurts.
6) Antivirus developers have learned this lesson almost a decade ago: how to scan and remove viruses without having all (corporate) users running as Administrators. Do you think they “broke the NT permission model” by doing it?
And last, but not the least: thank you for finally fixed your bloody utility to actually be useful. Now if we could just explain your lessons to those “programmers” that are making various motherboard temperature monitors and similar junk: they need a lesson or two as well.
Yet another story breathlessly posted to Slashdot by some clueless kid who didn’t even take time to read it first. If it kind of almost seems like it might be an anti-Microsoft rant, well then, green light for sure!
Nothing to see here. Just a couple guys who’ve learned how to program on Vista in the presence of the UAC model. Move along now.
Just a note, I’ve seen a pretty senior VP admitting that whatever security gains from UAC was from making the ISV’s lives miserable if they didn’t tighten their act, security-wise, according to Microsoft’s lights. UAC itself, in that article was not meant as a security measure in itself, just a nag screen. I wish I could find the original article.
The author discovered, as many ISV’s have, that it’s possible to code around Vista’s UAC with a privileged service. We didn’t hear how the author secured the service and client from misuse. Are the installed binaries signed so they can’t be torjan-ed. Is the interprocess communication between client and service secured so that it can’t be misappropriated? If these type of measure are taken then the ISV has gotten the concept that Vista can be a more secure if the applications are written to take advantage of the security features.
Haven’t you turned your program into a denial of service exploit by making it a service accessible by user-mode code?
mark russinovich did a great blog post a while back on UAC not being a security boundry.
he discusses it in some detail in http://channel9.msdn.com/Showpost.aspx?postid=294410
I feel your pain for having to split a simple program into two, but your ranting is way off the mark.
“Any program that UAC blocks from starting up “for good security reasons” can be coded to work around these limitations with (relative) ease.”
You haven’t coded around them. Your users have granted your application Administrator privileges during installation.
Game Over. All your base belong to us.
Once you’ve acquired Administrator rights the machine is yours and UAC’s role is done. If you had bypassed UAC without the user explicitly granting Adminstrator rights your rant would be completely justified, as it is, it’s merely misinformed and wrong.
The fact that Vista even has the UAC built into it… from a computer geeks point of view .. it just plain sucks, it nags, it wont shut up either… However.. from a general non-technical point of view (Courtesy of my gf and children)… UAC is fairly useful.. Its actually made them think first.. when going to a website that has malware or some other kind of trojan behind it.. now mind you.. i’m not praising Microsoft for the UAC either.. UNIX did it first with Sudo… Microsoft basically took that same idea and tried to make it their own..(and failed IMO).
In conclusion.. the UAC is only useful for the non-technical pple who are unaware of all the crap thats out there on the internet.
Keep in mind that by adding a privileged service to the system that any user can communicate with via standard IPC, you may have created a privilege escalation vulnerability. Did you do anything special to prevent a low privileged user accounts (such as the one used by Internet Explorer) from accessing this service? If an evil client talks to this service, can they force the system to reboot into a bad state, or corrupt the boot process? Developers have been insecurely “working around” privilege separation models for years, with some pretty nasty results.
This is pretty bad, it’s not remotely a hack. In fact its exactly the way Microsoft wants you to structure your apps. I’ve written programs myself that work just like this, there’s probably tons of white papers explaining how to do this on MSDN. One of the points of UAC is to encourage developers to structure their apps properly and thus avoid UAC consent dialogs annoying their users.
I love this line: “On Windows XP – where everyone runs as an Administrator and there are no annoying UAC prompts – it was a non-issue.”
Everyone didn’t run as an Administrator in XP. Developers, such as you, just assumed that, and that assumption created an environment where viruses, malware, and reinstalls became the norm.
I haven’t run as administrator in Windows for the past 12 years. If you know the basics behind Windows security, working around bad programming is not that difficult. Make me jump through too many hoops, then your program gets uninstalled.
I, for one, welcome UAC. Finally, developers will write programs the proper way, instead of the lazy way based on false assumptions.
From the sounds of it, iReboot 1.1 will work for non-administrative users, whereas iReboot 1.0 almost certainly didn’t.
If so, this is a perfect example of what UAC was actually invented for; to force developers to write software that works for people who aren’t logged in as an administrator. Good thing too.
http://arstechnica.com/news.ars/post/20080411-vistas-uac-security-prompt-was-designed-to-annoy-you.html
Microsoft haven’t said anything one way or another, but it wouldn’t surprise me to see a version of Windows in a few years that by default creates a separate non-administrative account for the home user, and encourages them to use that for day-to-day activities. UAC is just the first step towards making that sort of thing feasible.
Uhhh sorry but your “hack” isn’t a hack after all. This is EXACTLY how you are supposed to code an application that requires administrative priveliges to run with a standard user account. It is how things SHOULD have been done, in fact if developers had been doing this all along we could have been running as standard users on 2000 and XP.
UAC is doing exactly what it is supposed to do and that is get lazy programmers to fix their crap.
Just to clarify:
Both iReboot 1.0 and iReboot 1.1 required administrator privileges to install. They both still do the same exact system tasks. But iReboot 1.0 – the quickly-written application – required admin elevation each and every time a user wanted to run it; whereas iReboot 1.1 uses the service model to get around this requirement.
We’re not suggesting that Windows’ security is broken for letting developers employ the service model to get around the UAC nags – just that it’s broken because this shouldn’t be a requirement in order for applications to run in an elevated mode.
Perhaps the original article wasn’t clear enough, but here’s the thing.
From a security point of view, both program have the same initial limitations. They both require UAC elevation to install. They both run the same tasks. They both are used by the same users.
But Vista forces developers to do the extra work of splitting the program into two parts, without gaining any security, etc. as a result. So why do it if the resulting program isn’t any more (or less) secure?
“From a security point of view, both program have the same initial limitations. They both require UAC elevation to install. They both run the same tasks. They both are used by the same users.
But Vista forces developers to do the extra work of splitting the program into two parts, without gaining any security, etc. as a result. So why do it if the resulting program isn’t any more (or less) secure?”
That’s two different situations. Version 1.0 ran as non-administrative user. Version 1.1 has the service running as an administrative user.
Version 1.0 requires UAC each time for a reboot because it’s a non-administrative user performing the task. Version 1.1 requires no UAC because it’s an administrative user performing the task.
Basically version 1.0 didn’t use it’s temporary installer Administrative priviliges to bestow ongoing Administrativeness.
I know you’re getting a hard time from all these comments here and on /., but I humbly suggest you do a little more reading into the admin vs non-admin user, you haven’t quite understood the point of it.
steveg, I understand what you’re saying – I really do.
That was exactly the line of thought we followed – “we have the admin privileges during setup, let’s make good use of them.”
The question is, why should we be forced to split the app into two?
IF we decide that it’s OK for users to be prompted every time they run iReboot (from the opinions expressed in the forums, they didn’t mind so long as they didn’t have to open the app each and every time from the slow Vista start menu), why should Vista decide that it wouldn’t allow our program to ask the user to elevate iReboot?
The only thing that comes to mind is improving the end-user experience. But from every other POV – security especially – it makes no sense to force developers to switch to a client-service model for their app to run in the first place; when no additional security is gained.
Good user experience has always been a developers’ choice – not the OS makers. Vista itself is a testimony to that matter; Microsoft should certainly be focusing on boosting the user experience of its own OS before forcing this sort of behavior on 3rd-party developers.
This leads us to the deduction that UAC is not actually accomplishing anything other than making lives much more difficult.
At any rate: lesson learned. iReboot 1.1 released. Client-service model templated and ready for re-use.
🙂
This has nothing to do with making the app any more secure, it has everything to do with training developers.
I have not been using Windows at administrator in over 8 or 9 years and as a result, I have NEVER had a virus, spyware or malware attack.
It is time developers stopped writing stuff to the windows directory, all over the registry, in weird locations they should not e.t.c…. and if you do want to do that, I want a warning to tell me that you are going to!
UAC is brilliant and alerts me to when ever a developer has done crap things.
It is not designed to prevent security breaches in a application, it is there to tell me, the end user that you are installing something on my system that can affect me… once it is there, if it was spyware or something I installed, then it is my fault…. but I have the option to cancel the installation and I KNOW that you were trying to do something that requires privileges.
To me, it is working how it should… you have not done a “work around” you are just following best practices and doing it how you should all along.
Dear Mahmoud,
It does appear you have not fully grasped the implications of UAC and what it’s trying to do.
Remember Windows XP was a broken model where everyone basically had to run at an Administrator level to get programs to work. Why? Because application developers forced everyone to do this as it made their programming easier! Why code for security when you can ignore the issue and save time and therefore money.
The result is the rampant malware infested world we have today on the Windows NT platform. I don’t believe that anyone has ever said that UAC would be the end of malware but it does make it more difficult for it to install without the users permission.
The fact you have to spit your very useful program into two parts now (a system level process which accesses restricted functions) and a user level GUI is how it really should have been done from the beginning! Look at Unix and variations (including MacOS) and how these work to separate processes and enforce permissions.
UAC has to be grafted onto the existing NT codebase in an effort to improve the situation. UAC could fix it completely however because compatibility is also important factor in the in the MS world view it would probably break most applications in the process.
Frankly I think the default state for UAC should demand account credentials not just interactive permission to ensure users think about what they are doing before they click on “OK” to install applications.
If you cannot see why granting auto-running applications full admin/system level permissions at run time is a bad idea and why this was *always* was a bad idea, may I suggest you load up a test PC with malware to see what the results are! 🙂
Lets hope the API you used for interacting with your system level process has no exploitable flaws which can be exploited otherwise there could be problems here later on.
How about submitting your code for outside independent review so we can get an indication of what issues might be present and how they can be mitigated?
Kind Regards
Simon
A simple example of how this might make things more secure.
1) User requests shutdown
2) Service checks if there are other users connected
3) Services reports that user can’t shutdown at this time as there is a second user logged in.
If this was all one application then the user requesting the shutdown would need to have permissions to check if other users are logged in. With the split then they would not need that permission only the service would need that.
This is only one example, I’m sure there’s loads more, e.g. writing to the event log that the user is rebooting or running some code that validates that there is an alternative OS installed before doing the reboot.
Andy, on a normal Vista machine any user can at any time reboot the machine via the start menu – so nothing gained here.
Plus, iReboot has always had code that checks if the boot options configured are correct and ensures they won’t result in a system crash or other such problem.
On a UNIX system you’d also split the application up having it run unprivileged most of the time but ask a more privileged component to do the work. You’d code the more privileged component to be very strict about security.
Still, I’ve had other problems with Windows security being hard for developers – in the area of Dot-Net code signing. So much is signed now, by both the developer and the installer when you have “click-once” or Office Addins. It can be powerful and flexible, but its defaults are restrictive and hard to use. What’s more – the defaults can be changed by an installation program.
I’m not sure how much more secure things are for the end user anyway. You install your given trojan infected application and grant it permission to install – then it can run riot over your system as before. The extra security comes down to “OK, so the virus installer has to do a chmod +x to allow execution. It’s a little less user friendly than chmod, but it’s still easy enough to do”.
Wow, you guys sound like you just wrote your first NT service and found out that it can do marvellous things that unprivileged users can’t, by doing IPC with a user mode agent without impersonating the client. Great, now this is what I call privilege elevation. And you circumvented and “easy […] coded around” the security boundaries by putting your code into the TCB by requiring it to be installed as an administrator. What is so fancy about that? I only hope that the IPC interface that obviously anybody can successfully call has no network interface…
There are basically two points of view here:
1) UAC is good because it forces developers to separate functionality requiring elevated privileges from the remainder of the program.
2) UAC is useless (for installed programs) because the actual program bits remain the same, except that they are now more complicated to write.
In my opinion both are correct. What I don’t get about UAC is why it needs to prompt at all, or at the very least be able to remember answers for future reference. The thing is, the operating system controls my hardware, and supposedly knows exactly when and on what I have clicked. Asking me to confirm my own actions is just pointless nuisance, and clear demonstration that the OS doesn’t know what it is doing. If UAC had been for processes launched from other processes it would provide the same security benefits as it does now (buffer overflow exploits not included, but that’s what DEP is for anyway) with 1% of the annoyance.
Now, if you want a nice security product, go download Sandboxie (ask Google). Great application to run untrusted applications in a protected file-system/registry sandbox.
I think a lot of the commentors are missing a very simple and important point…. iReboot (from what I gathered by reading the above and downloading it for myself) is a system program that NEEDS to do system stuff.
Running it within Sandboxie, stopping it from doing system modifications, etc. will leave it not working.
I think these arguments are going around in circles. Like Morten says, both opinions are valid; I guess MS just decided that in this particular case they prefer user simplicity over developer happiness – not really a big deal; certainly not worth this war in the comments and over on /.
We should be able to trust the OS to know the hardware. If we did
We wouldn’t need “Trusted Computing” for our own security because the OS’s memory
manager will ensure that programs can’t upset each other. (Still, the record industry
may like it)
We wouldn’t have this panic about people taking USB storage into the work place if the
OS didn’t allow any user to mount any storage device. Panic and epoxy resin your USB
ports and you’ll find someone just connects some other storage, like a WebDAV drive.
(true, UNIX doesn’t completely close this as you can find ways of uploading
TopSecredDocument.doc off the machine – back to “trusted computing” – still at
least you can lock down storage)
As for user friendliness – Windows in the past has been known to cry wolf too much. “Warning! This plain text file may harm your computer!” Users, if they even understand it, have learned to ignore it. Maybe there’s a problem with the attitude that says “Computers should be so friendly I shouldn’t have to be bothered to learn how to use one safely”, but too many of these things don’t help.
More awesomeness, which I have complained to MS about but you didn’t really emphasize, is the need to have a custom API surface on you LocalSystem service which is necessarily accessible to processes running as normal users. The recommended mechanism for implementing this is to develop your own custom RPC (there’s no built-in RPC’s which are allowed to communicate like this). That means for every vendor which needs to do this to get their app running on Vista, you have a new, custom, untested, unverified, 3rd party created API surface accessible to normal user applications to a service with full control of the system.
Think you had issues before with buffer overruns on PostMessage handlers in services which displayed tray icons (which was the nominal reason for the change)? Wait till there are 20 new API surfaces, all different, all custom, all without Windows Update to fix inevitable bugs, of various levels of support, etc etc etc. They didn’t just drop the ball on this; they threw it down so hard it stuck in the ground!
Nick, we’re using IPC models that ship with the .NET framework as the basis for the communications between the iReboot backend service and the frontend client processes.
The .NET Framework has really simplified IPC-style coding on Windows (for those that care, that’s the reason for the seeming conflict in the article. IPCs aren’t easy to design & develop, but with .NET they’re not so hard).
Best of all, the IPC models that ship with the .NET Framework already have integrated NTLM authentication to prevent against unauthorized remote access. We built some extra security around what’s already there, but it’s a very framework to work on top of.
Of course if you can’t use .NET you’re out of luck… but for anyone either starting a new app or needing to rewrite an existing (.NET or otherwise) application to take advantage of the IPC model to implement such features, have a good look at the different communication servers and channels available for your use in .NET 2.0 and 3.5. The latter has some really nifty improvements to both performance and security.
You are saying that if the registry had a key that said “run elevated” you would not be claiming that UAC is broken. So, according to you, UAC would be fixed by adding a registry key to save you coding time. Do you see the stupidity of this reasoning? Maybe you meant to say simply that running a process with admin privileges in Vista is more cumbersome that in XP and that you are annoyed by it. This has nothing to do with UAC or with a security flaw. You can see that, right?
To Mahmoud:
Yes, I should clarify that the problems I described only effect non .NET applications. If you are able to write your app from scratch, and you can do everything you need to in .NET, and you’re not concerned with the download, compatibility, speed, and obfuscation issues, then by all means use the new .NET IPC mechanisms. For us (and I suspect many other ISV’s), this is not really feasible; but it should not be as much of a problem for .NET apps.
Diego:
It’s stupidity to think that the only problem with splitting a program into a service and a client is with developer time wasted.
Splitting a small, simple, and to-the-point app (like iReboot, I guess) into two wastes memory, introduces new opportunity for security vulnerability, and makes everyone’s day miserable.
I hate applications that install services for no good reason. I guess this would qualify as a “good reason” because the devs at NeoSmart were forced to take this route, but in the big scheme of things, this is a useless service (esp. compared to XP where it would have had no point whatsoever).
Mahmoud (and the rest of the guys on the iReboot project):
I think you guys have a very valid point, but perhaps your post leaked more frustration at Vista than was wise… perhaps taking things a bit out of proportion? Don’t let the heat from the comments get to you – iReboot looks like a great app and the rest of your portofolio looks pretty sweet too!
Nick: At the risk of pissing-off any hard-core Win32 coders here – the drawbacks of .NET pale entirely in comparison to the cleanliness of the code, the productivity boosts, and the security overhaul (*so many* security vulnerabilities are caused by developers forgetting to handle win32 objects with the high level of care they need).
As for some of the other issues you raised: We’re using {smartassembly} to obfuscate & optimize our apps in one go, it’s pretty good for small- to medium-scale projects, though I would hesitate for a long while before recommending it for anything larger than that given its lack of cross-compilation/obfuscation.
Oh, and .NET applications (esp. v2) have a higher compatiblity-to-effort ratio than their win32 counterparts for anything other than a hello world 😀
George: Thanks 🙂
To Mahmoud (and OT, re .NET vs native code):
The use of .NET very much depends on the scope of the project and project-specific factors. For example, my company builds NT admin apps. We have an existing C++ code base well over a million lines long, and a relatively small group of developers. Our apps make use of Windows capabilities which are not always exposed via the public API for competitive advantage. We were pleased to learn that our apps, or at least the remote agent portions, should still run on the “more secure” core version of Windows which will not include the .NET platform. Our customers (typically large companies) also typically have specific versions of .NET which are installed and/or allowed in their environment, whereas every installation of Windows NT 4.0 and up can run our apps out of the box. We also use several 3rd party libraries and interfaces, not all of which have .NET equivalents, or where the method of usage would require native bridging anyway.
We could go to .NET, but we would lose some competitive advantage, require a huge rewrite, and will not support everything we currently do. I don’t deny that there are some advantages, but it just doesn’t make sense in our case.
George and others: you’re still missing the point.
iReboot 1.0 was /useless/ to me. Why? Because I’m not logged in as an administrator. I am an administrator – in fact I’m a domain administrator – but for day-to-day tasks being logged in with an administrative account is a stupid and unnecessary risk. I log into my desktop as an administrator maybe once every few months, when I need to install new software or do other similar tasks.
Assuming iReboot 1.1 will work in this scenario, UAC has done exactly what it was meant to do; it’s made the developers redesign their program so that it works properly for people who follow this really basic security practice. This is worth the small additional load on the system the extra process creates.
Morten: If UAC wasn’t annoying enough, it wouldn’t work. See
http://arstechnica.com/news.ars/post/20080411-vistas-uac-security-prompt-was-designed-to-annoy-you.html
I’m not saying I entirely agree with Microsoft on this, but I totally agree with the goal of making developers write software I can use without taking the absurd risk of logging in as an admin all the time.
Mahmoud:
“Good user experience has always been a developers’ choice…”
The thing is, Microsoft have been trying to persuade developers to program for non-administrative users for years. It just didn’t work. There’s been a vicious cycle: users log in as administrator because otherwise too much software doesn’t work, and developers don’t bother making the programs work for non-administrators because (and I quote) “on Windows XP […] everybody runs as an administrator”!
UAC is a pain, but it does seem to be working.
“So why do it if the resulting program isn’t any more (or less) secure?”
The program isn’t any more secure, but the system is – at least potentially – because the user now has the option of logging in without administrator privilege.
Hopefully in a few years all developers will have gotten this right, and a future version of Windows can make a non-administrative login the default.
Mahmoud:
“Good user experience has always been a developers’ choice…”
The thing is, Microsoft have been trying to persuade developers to program for non-administrative users for years. It just didn’t work. There’s been a vicious cycle: users log in as administrator because otherwise too much software doesn’t work, and developers don’t bother making the programs work for non-administrators because (and I quote) “on Windows XP […] everybody runs as an administrator”!
UAC is a pain, but it does seem to be working. Whether the benefit justifies the pain is a separate argument.
“So why do it if the resulting program isn’t any more (or less) secure?”
The program isn’t any more secure, but the system is – at least potentially – because the user now has the option of logging in without administrator privilege.
Hopefully in a few years all developers will have gotten this right, and a future version of Windows can make a non-administrative login the default.
Sorry about the double-up. Got an error page and thought the first comment hadn’t gone through.
If iReboot is a user-initiated application, why shouldn’t it do what my openSUSE Application Updater forces me to do whenever it tells me I have new software updates to install: ask me for the admin password? Or be run using “Runas”.
Whether it runs as a service or not is irrelevant, and whether it has to be coded that way is irrelevant. What matters is that its privileges cannot be elevated without the admin password.
When I first heard about the UAC, I assumed that’s what it was. Then I found out it was just a stupid nag screen to remind people not to do stupid things that require admin privileges, while still ALLOWING THEM TO DO STUPID THINGS WITHOUT ADMIN PRIVILEGES.
The stupid of both worlds.
Either the machine is running with one user who is both end user and admin, or it is not. If it’s multi-user, no way the end user should be able to do admin tasks without knowing the admin password. If the machine is running with one user, they should know the admin password – just ask for it and then request elevated privileges from the OS.
It’s not rocket science. I don’t why geeks can’t get this right.
It’s a similar problem with partition editors. In twenty years, not one partition editor has gotten it right. They ALL screw up under certain circumstances. Yet the partition table is a few bytes with a fixed definition (even though that definition varies between OS and even versions of Windows – the problem is lack of documentation.) I used to use Partition Magic on my dual-boot Windows/Linux machine, and it couldn’t even see my partition table despite both Windows and Linux working fine. Turns out the Windows 2000 prior to Service Pack 4 would “silently” screw up a partition table in some (undocumented) way that would only show up on certain drives if you exceeded the 137GB barrier.
Then we had Fedora Core 2, I think it was, that left out two bytes in the table and Windows wouldn’t boot in a dual-boot situation.
Then last week I used BootItNG to resize a partition on a machine with a Ghost OS image partition – and Windows was hosed. BootItNG has never failed me before. Clearly somehow the partition table had been edited previously in such a way that BootItNG was forced to silently screwup.
My point: geeks just can’t get the simple, straight-forward stuff right. They HAVE to make it more complicated than necessary – and then fail to document what they did to screw it up.
Woody Allen described the IT industry perfectly when he said, “Nothing works and nobody cares.”
“Windows Vista’s newly-implemented security limitations are artificial at best, easy to code around, and only there to give the impression of security.”
If you installed the service with admin rights you didn’t work your way around anything dumbass. UAC is working just as designed. Now if you can install without admin you have managed you way around it.
Re: Richard Steven Hack
It sounds as if this program wouldn’t want the average user to have to enter the admin password every time it is used. It sounds like a single user desktop scenario where that single user just wants to flick the switch and be done with it.
The model, if you’re thinking of Linux desktops, sounds more like HAL and DBUS where things like mounting storage media requires administrator privileges but for you as a user it just happens. On my system I note that my user is in various security groups including things like audio so I can do sound, lpadmin, scanner, netdev so I can control networking and for using USB devices I’m in the plugdev group. However I can create users without these permissions and all the service accounts on the machine don’t have these permissions. The default policy on a user orientated Linux system is quite friendly, but it’s very configurable. Both Windows and Linux are fiddly for the average user to configure policy because you have to understand it.
On both Windows and Linux increased security does mean increased complexity, both for developers and administrators. A lot of the stuff in Dot-Net and Vista doesn’t seem to make sense on the desktop but would make more sense in some organisations where you have the administrators who know what they’re doing and who can set the policies. Unfortunately too many organisations I’ve worked with don’t have that which is a shame.
Some of the hoops you have to jump through seem excessive though and on both systems (barring Capabilities on Linux where enabled) once you’ve given that administrator password the app installer can do whatever it wants making the deeper stuff seem redundant.
Maybe one way around it is software as a service – central storage – central security – managed and guaranteed (because you’re paying for it) backups and hopefully administrators who know what they’re doing. Technology is getting there. In some ways it’s been there for a while. There are a few questions, both legal and practical, to ask about it. Look at things like GMail and a lot more of our lives are now online.