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.
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.
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)?