Slashdot Mirror
Vista's Troublesome UAC is Developer's Fault?
MythMoth wonders: "We've heard all about the pain and discomfort of working with Windows' User Account Control (UAC) switched on, but now Ian Griffiths is explaining that the developers are the problem — they brought it on themselves. In earlier articles we have heard that Microsoft think that everyone should do it like this — Ian does acknowledge that things are better in the Unix world, but is he right? Is the onus now on the developers to help fix a problem that they did not cause?"
Rather than ask the user for permission on every operation, what other ways could Microsoft have improved Vista's security?
Hmm, I'd say he's got a good point - there's simply not a culture of privilege awareness in Windows developers.
Perhaps Microsoft should set up an audit unit and start giving software a 'UAC-compatible' tick if a piece of software has minimised how much UAC approval is required if its turned on, allowing the publisher to put it on their box so that the customers can tell. Who knows, perhaps one day the UAC system might actually be viable.
on Windows, on Unix and on OS X.
The problem on Windows is that it is a single user operating system with delusions of being a multi-user operating system.
The problem on Unix is that it is a time sharing operating system which people inexplicably use as a workstation operating system.
The problem on OS X is that there are no serious threats, so no-one has any idea if their security model does anything because it never gets tested.
And the problem with all three of them is that they assume that the program will always do what the user wants and therefore the program should inherit permissions from the user. On Windows that was never true. On Unix it was only true back when all users were developers and had enough time to read the source code to all the programs they ran and thus felt they could trust them. On OS X it was actually true because, again, no-one writes malware for OS X.
The security model should be, quite simply: the program has a manifest that declares what permissions it needs with a fine granularity. The permissions should be placed into a hierarchy. For example: writes to disk -> writes to user files -> writes to user files of type X. The user should be able to inspect these permissions to determine if they are acceptable. If they are not, then the user should be free to uncheck "required" permissions.. the program should still run but those functions of the program which invoke a required permission should cause a prompt. The prompt should give the option to deny the request, or fake the request so it appears to the program that it completed successfully.
And yes, developers should use this mode.. and they would, because it is actually useful instead of just being a pain.
How we know is more important than what we know.
Indeed, and I would take it one step further. I'd append to each UAC a description of why it's bad practice. Something like....
Application X is trying to do X. This is behavior typical of malware or virus activity, but can be a product of poor developmet practices.
It isn't going to win any friends, but will certainly bring their ego's into play. Of course if MS really had some balls they'd just make developers live within their install directory. Nothing gets in or out without a open/save dialog, provided by the system of course.
But I also think it's awesome that MS basically absorbed the audio stack. But only because I hate Creative even more than MS. It took 15 years, but incompetent and destructive finally caught up with them.
I suppose, like the US, Microsoft will do the right thing. Once all of the other options have been exhausted.
Platform advocacy is like choosing a favorite severely developmentally disabled child.
Once people start to understand UAC and how it works, people will begin to harness it and accept it rather than shun away from it.
/priv" in a normal shell under the administrator logon. Now open up a shell using "Run as administrator" and type "whoami /priv".
.manifest file and place it in the same directory as the .exe. The manifest file is just an xml file that tells Vista that the .exe will require administrator privileges to run (queue UAC.) Google "vista manifest" or check this out for more information: http://channel9.msdn.com/Showpost.aspx?postid=2112 71
UAC allows administrators to be logged in 24/7 without having 20+ privileges until the actually need that power. 99% of the time UAC will strip the administrator privileges away from the administrator and grant them with 6 SeXXX privileges to work with. It does this by using two different tokens instead of one. The first is a normal user token, and the second is the real administrator token. When you see that screen where UAC asks for elevation, that's when Vista will grant you the administrator token. Don't believe me? Type "whoami
Vista isn't the shining example of everything secure, but it sure is lightyears ahead of XP and a real good step in the correct direction. Windows users will whine and gripe about it, but they will eventually have to go through the same stuff the *nix crowd did along time ago when people were logged in with root 24/7.
If you require Vista to elevate you with certain apps, then create a
Enjoy..
h
Valkyrie is about to die! Wizard needs food -- badly!
I've spent the last eight years of my life packaging and deploying apps for Corporate environments.
In none of those environments were the users Administrators (or even Power Users). I have written a few scripts and applications to work around some issues, but in general, it is a case of setting the appropriate permissions in HKLM and \Program Files\. It takes some work, but I have only ever had one seriously intractable application.
For the past 4 years I (and my family) have run primarily as users on our home PCs. Its a bit of a pain in XP, and I wrote my own Privilege escalation tool to make some things easier, but again, it is now pretty smooth. Even games work as users, with the appropriate settings. Vista (on my new laptop) is far easier, and no less frustrating than Kubuntu, which is always asking me to sudo an elevated operation.
UAC is a good thing - it's smart, and as developers get with the program, will add protection (not frustration) for users.
What's wrong with asking the user for permission on every operation? That's what my linux box does. It's called "su", and it makes me type in my password to make system changes. In fact, that's what every real operating system has ever done. Welcome to the real world.
A major reason for the "insecurity" of windows, IMHO, is the culture of its users. You get people who still remember 95 and 98, (and DOS) and who like to run everything as root. They don't want to be bothered with those nag boxes. But nag boxes are what it takes to secure a system. Security requires some effort on the part of the user, too. Funny how things work like that, isn't it?
See, in the beginning, a single user OS was perfectly OK. Even if you hooked your DOS machine up to the internet, it was probably a terminal, not as a computer in its own right. And really, they had so little RAM that a full-on operating system like linux would be massive overkill. A cell phone is a multimedia powerhouse compared to those machines.
But the microcomputers got bigger. They got a networking stack. People started using them like real systems instead of big, featureful, programmable calculators. They went mainstream, too. But the mindset of the users and developers was (and still is) somewhere way back in the 80s. The developers have gotten better; they add in UNIX features with every windows release. But the users, for the most part, just want to buy a box from Dell and have it work out of the box, like an appliance. Which is a fine thing to want, but those same users are also the kind of people who will install the purple monkey, become phishing victims, run binaries they got off P2P, and so on. And unless Microsoft locks people out of their own computers, there's not a damn thing they can do about that.
So while it was acceptable to bash Microsoft back in the day (no firewall, single-user mode, instability, etc), most of these problems have been fixed. Oh, sure, Windows is no OpenBSD. It's kind of kludgy, compared to linux, or OSX, or your *NIX-like system of choice. But at this point, if your system gets hacked, its probably your own dumb fault. Anymore, if you whine about windows without mentioning specifics, you just end up looking stupid, not 1337 and educated.
No, I am not a Windows fanboy. I don't dual boot, either, although I do use VMWare when I absolutely must. But it still pisses me off to see such obvious bullshit. Some of it is Apple propaganda, but a lot of it is propagated by windows users themselves. Which is understandable, I suppose, but not particularly productive.
I think that this is, in turn, a consequence of earlier Microsoft operating systems (Windows 3.x to ME) that did not have security features worth mentioning. Unix had a clear differentiation between user and admin (root) rights since decades. Windows did not, and essentially everyone was administrator.
As a result, lots of applications got written that implicitly required admin rights, accidentially or because it was the path of least resistance for the developer. As a result of that, people got used to work as administrators all the time on the newer systems (Win NT and later) too. As a result of that, there was less pressure to clean up the applications.
Now Microsoft is trying to break that vicious circle with UAC, but it seems they are not very successful... as it is once more the path of least resistance to turn it off
C - the footgun of programming languages
Actually, passing NULL as the first parameter of CreateEvent is almost always the right thing to do.
Of course the vast majority of developers don't actually know that - they just pass NULL out of laziness. But it turns out that if you spend the time it takes to learn the intricacies of the Win32 security model, you'll still end up passing NULL once you understand what's happening.
You just get to feel smug about it.
Ian Griffiths
Note: I'm normally a Microsoft defender here, but I've spent too much of the last eight months dealing with Vista breaking-changes. Onto the rant...
This is such utter nonsense. UAC first came in, IIRC, in Beta 2 (May), but there were far too many problems with Vista over the beta/RC cycle to be workable. UAC was too annoying to leave turned on while trying to figure out the real bugs. UAC is still awful over remote desktop on a slower connection, as it blanks the screen. This cycle was nothing like the 2k or XP cycles with regards to beta and RC stability and direction.
One of our long-released apps went through this:
Beta 1:
Some draw issues, crashes on exit.
Beta 2:
Some draw issues, just fine.
RC1:
Some different draw issues, crashes a helper process on startup, then a second crash, completely, app dead.
RC2:
Some completely different draw issues (others gone), otherwise fine.
Release:
Same draw issues as RC2, crashes a helper process on startup, annoying help pop-up for any plug-in expecting old-school help to be available.
This was a released app for which the shipping bits did not change, at all, over the Vista cycle.
Now, it gets worse with UAC, because there are things that get more restrictive when the user gets sick of UAC and turns it off. The most obvious example is the "can't write to the TEMP folder" defect (by design? The designer is defective.). This kept several installers from working properly. If the user shuts UAC off, apps can no longer write to the TEMP directory and run their expanded installer app (winzip installer approach). This means that getting tired of UAC and pulling the plug on this behavior still interferes in the use of the system. In this case, it will hand the user a cryptic error message and no direction.
They went down this road with things like broken file-sharing and remote-desktop access with no-password accounts in XP, and it continues throughout Vista. Users of Microsoft products are regular victims of hidden behaviors, where seemingly simple changes can have much-delayed distant results.
Microsoft once cared a great deal about backwards compatibility. Now they seem to expect all software vendors to re-code, re-compile, re-test, and re-deploy for an OS change, and that OS was a moving target for the year preceding its release.
We're handling it, but what happens to the software that was orphaned by companies that died (or moved to a different platform)?
1. UAC is not SUDO
.NET, complete with its own security penetration API. :p
UAC is completely unrelated to sudo. It's an extension of the proxy privileged service scheme they've been using all along. It's not a bad model... it's much like what SafeTcl slave interpreters use... but it shouldn't be confused with "su", "setuid", or "sudo" in UNIX.
2. What they did wrong
Security is like sex, once you're penetrated you're ****ed. UAC, reduced privilege mode to run IE in, all the extra dialogs and warnings and security centers of the last ten years, they're all attempts to reduce the damage or pass the blame for the penetration on to the user. The solution is not to add more layers of annoying mitigation after IE, Outlook, and other applications that use the HTML control are inevitably penetrated. The solution is to redesign the HTML control so that it doesn't provide a security penetration API (the way ActiveX works in IE, that's what it comes down to) in the first place.
Instead, they present Silverlight, based on