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?
- First few times: What is this annoying thing?
- Next few times: Well I guess it's better than not knowing
- After that (without reading) click ok...
So does that mean it's not working, wasting my time, AND training me to ignore security warnings? Honestly I don't have a better solution except for the rhetorical question "why can't people who exploit users justTurning coffee into code.
How many unix developers run as root? Probably because it works in the first place! Seriously though.. windows is beyond simple refactoring and I believe that vista is the evidence. The unix model is simple and effective but best yet scales reasonably well. Daemons run as root? No.. nor do they run a joe or bob. Even as sudo, you can still limit what commands you can run. SELinux takes things to a whole other level.
----
Go canucks, habs, and sens!
I kind of like the concept of UAC. I mean the messages are so annoying that hopefully developers will start to avoid getting them pop up.
Hopefully this will cause applications to stay the hell out of the Windows directory, the registry and wherever else they seem to think would be a good place to sprinkle data randomly. I pine for the days of being able to uninstall a program fully from my system by deleting its folder. Or being able to simply copy a configuration file from one computer to the next and having all my settings preserved.
Perhaps I'm forgetting how bad that system was in the DOS days, and I'd welcome people reminding me, but it is looking pretty good at the moment.
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.
Is there an onus on developers to actually write code that's aware of privileges? Absolutely. Windows developers have gotten a free ride with respect to access rights for a long time, but that party's over. But can Microsoft just throw up their hands and say "Okay guys, it's on you now"? Absolutely not. The reason developers have gotten away with this for so long is that Microsoft's own conventions and practices encouraged this. Users were set up with root-equivalent permissions by default, and there was no authentication mechanism in place (and there still isn't).
Microsoft should've deprecated UAC heuristics and put a time limit on them. They should've given developers a year (or so) to update their applications to be aware of privileges, and then simply remove the UAC heuristic features that "guess" whether an application needs privileges. So if you run an installer built for Windows XP, it doesn't get the right privileges without you explicitly launching it with admin rights.
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!
UAC reminds me of car insurance... its like limited liability or whatever...
You get pulled over for speeding, get asked if you have Insurance(click yes), you give your card and you're ok, ticket aside.
But when you rear end a new M3 BMW... that shit changes... REAL Quick...
And Ive seen graff scrawled clearer than that goddamn word in the "Please type this word in the image" picture... fuckin dammit!
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.
UAC is pretty much essential to meet the mutual goals of:
a) run old software designed for prior windows versions.
and
b) be secure.
You might want to allow, for example, an online game to delete files IF those files belong to the game, and only to the game, like obselete maps, sound files, etc. But you don't want someone to exploit a bug in the game online to hose your system; like the bug I found in Counterstrike (old version, long fixed) where putting "%D%D%D%D%D%D%D" as your playername would crash it out (classic printf issue).
You could possibly run an app in a VM 'sandbox', but that idea breaks down as soon as you try to cut-n-paste from one app to another, or two apps want to write files in the same directory... what should it do then, prompt for Cancel/Allow for each breach of the sandbox? or have the user define complex sets of which applications are allowed to talk to each other? I did that for a Linux setup, I made seperate accounts for each service, one for the Fax receiving, one for Apache, one for each instance of the DVR simulator, one for DistCC, one for web browsing... and configured them for exactly, and only what access each needed; the Fax could put files into a directory to be served by Apache, but could not touch the templates and other pages, and nothing Apache did could touch the Fax archive and configuration, each simulated DVR had its own IP address, and couldn't see the others except via network packets. It was terribly complex, and done as a learning experiance. because everything worked perfectly when run as one user, or if p[ermissions were opened up, but it took months of spare time to get all the permissions exactly right as seperate users.
Unless you can be absolutly sure that EVERY action a program may take is approved, it needs to be controlled. As apps get fixed up, and Vista gets service packs or whatever to improve support for specific apps, the issue will fade, but never be completely gone, because sometimes, it'll save the users ass.
That won't work for the same reason that the current Windows security model doesn't work.
It's too much trouble.
I believe this is one of the main reasons why UNIX applications generally do not play fast and loose with permissions. The security model is very simple. A process is owned by the account most suitable for the role it will perform. There's no need for complicated LPSECURITY_ATTRIBUTES structures. (And yes, I do think that even those are too complicated for most purposes, so you can guess what I think of the more esoteric aspects of Windows security tokens.)
Be honest, if you program for Win32, how many times have you just passed NULL as the first parameter of CreateEvent()?
If you want to make people do the Right Thing, make the Right Thing easier to do than the Wrong Thing.
Rather than ask the user for permission on every operation, what other ways could Microsoft have improved Vista's security?
Excuse me, how would such a knowledge help anyone but Microsoft developers? No one but those developers have access to source code, certainly not Slashdot readers.
The fundamental problem with Windows Security architecture is that the Operating System thinks it is better, wiser and more powerful than the user. In Unix, the user is the boss.
If admin users can examine every single running process themselves, and there are no obscure registry settings, binary blobs, TPM, DRM and other 'heuristic' aka guesswork techniques to deal with.. the system can be made secure. The reason is simple: If there is a malicious code that is poisoning the system, the root user can examine it and simply delete it.
The only exception to this rule would be rootkits... and by rugged designs like SE Linux, removal of LKMs, etc. the possibilities for such rootkits can be minimised largely.
And finally, if there exists a simple mechanism for restoring an entire filesystem with file level backups (on separately dsignated partitions for instance), ease of restoration is guaranteed in case of security breach. Windows Vista's System State image rollback is simply more complexity without any added benefits from the simple tar command.
If Vista must be really secure, the registry has to be removed, the device drivers must be open source, the entire OS kernel must be available free for inspection and rectification, the DRM, TPM and PVP kludges must be knocked out... in short Windows should be a mere operating system. I bet that every single OS developer at Microsoft realises the above truth... they're just trying to create a situation where the market tries to follow their Defective by Design philosophy.
If you keep throwing chairs, one day you'll break windows....
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
@ECHO OFF
PROMPT $p$g
C:
CD \NWCLIENT
SET NWLANGUAGE=ENGLISH
loadhigh LSL
loadhigh NE2000
loadhigh IPXODI
VLM
CD \
I cant imagine why parent is marked Troll. It's a ontopic reply, with informative commentary, directly from the source.
UAC cannot and will not mean secure computing. It's been pointed out before, that "may X do Y" dialoge comes up so friggin' often that users either turn it off or click "yes" on everything.
And that does not only apply to "clueless" users. Of course, someone who has no idea what the computer does and just why an application like explorer.exe has no business beyond the local net, will click yes on the "when in doubt, click yes or it won't work" presumption. The problem is that many Windows-Services are started in ways that make it impossible to determine whether a given program is supposed to do this or that, because there are many started using wrapper programs.
Many services are started using an application to start services. And you ONLY see that application, not (necessarily) the drivers it aktually loads. Some of them need to get access to very core deep functionality. And, unfortunately, can be abused to start trojans.
Generally, the problem lies in the untidy separation between system and user. As has been pointed out before, too, one of the problems is that developers didn't care too much about access rights so far, because you could readily assume that the user had administrator privileges, so key hives like HKLM were overused, even when unnecessary.
Another problem is that UAC is an "all or nothing" privilege mechanism, at least when it comes to installers. You either unlock the whole system or nothing. And this is even for a user with some knowledge no trivial matter to decide. You download a game from some demo page and it requests elevated privileges. Is it because it needs to set a key in HKLM, which is maybe unneeded but not critical, or is it because it comes bundled with some spyware that wants to root itself deeply in your system?
Basically, to me it seems that UAC is MSs way to shift the blame for infections away from them, and (mostly) towards the user. You allowed it to happen, we warned you, you clicked yes.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Do you REALLY want your save games to be deleted when you "uninstall" an app?
This extends to all data created by applications, e.g. documents created by your word processor of choice. Clearly, this is bad practice. (User) data and configuration SHOULD reside elsewhere. And that's not even delving into the security issues this would present. You don't necessarily want to share your settings or data with other users of the same computer.
Another thing: Unless you use Windows Explorer (or command line) to navigate to and run a program, you can't uninstall a program FULLY by deleting its folder. At minimum, you would need to delete the shortcut to the program from somewhere else - unless you want Windows to be constantly scanning e.g. the Program Files folder for changes... but something tells me, you wouldn't appreciate that ;-)
In total, we have three separate "components" to even a relatively simple application: user configuration, user data and the app itself. In most cases, the app should be accessible to all users of the machine, whereas neither user configuration or data should - in most instances, anyway (I would love for Picassa to be identical, including settings and data, for all users on the "family" computer). Ideally, these components would be be located in predefined locations (can anyone say "My Files"? No, not "My Documents", "My Files"), easily locatable by the user. Yes, that means burying them in the registration database (die!) or under "C:\Documents and Settings\[User Name]\Application Data\[Program Name]\" (or the equally horrendous Vista version of it).*
A properly behaving uninstall program should delete the application (completely, not leave a friggin' empty folder or random "I was here" file) and PROMPT for deletion of configuration - and possibly data.
*Note that many of the problems associated with multiple users on a single WINDOWS system would be at least mitigated by introducing a "home" folder. This would have been an obvious feature to implement in Vista, but no such luck.
Hey, he was BASICly making a statement.
vi +
Waiting passively for the programmers to change their bad habits isn't the best strategy that could have be taken by microsoft.
... admin work on the machine as intended. They found thousands of bad-behaving softwares that can work under this envrionment.
:
: : /. developpers will be slow to change. They don't write code "perfect by the book", code that "somewhat works" is enough for most of them. Read sites like this if you don't believe.
:
As you state those problems stems from bad programming habits. Developers that have taken the habit of writing critical data just like in the old DOS days : wherever it pleases them, ignoring the fact that some place are supposed to be reserved for admins only.
It has worked up to WinXP because either there wasn't any protection (older DOS based Windowses) or all users did run as admins by default (newer NT based Windowses). Now that VISTA finally tries to correct this and approach something that looks like Unix' habits - using admin-level privileges for doing
BUT THEY'VE TAKEN THE WRONG ROUTE AROUND THE PROBLEM !!!
With such problems you have three solutions
- IGNORE THEM. Let the bad-behaving software just crash or display error message. That would attract attention to the fact that those software are broken. BUT ! Most users will believe that errors appear because Vista is buggy. The new version will get a bad reputation (as if the rest wasn't enough) and no users would like to switch. Microsoft would loose valuable market shares.
-> So that's why microsoft doesn't do it.
This behavious only works on Unices because most of the other software function correctly and users guess that the problems comes from the badly-behaving software and they try to download a corrected newer version or a better alternative.
- ASK USER'S PERMISSION. Do some 'sudo'-style privilege escalation for every single action that would require admin rights. And hope that developer will notice and produce more Vista-compatible softwares.
-> This is what microsoft has done, BUT THIS IS FUNDAMENTALLY WRONG.
Because concerning users
- It floods them with a mass of annoying blocking popups asking for privileges. The users ends-up first answering OK to everything (and the Unix style protection is completly lost) and then they disable the whole UAC to stop the flow of popups. So it is as if it wasn't introduced in vista in the first place.
And concerning developers
- As pointed by other
- Changing may be difficult for them, because it would require re-doing the whole program architecture. Or it could pose problem to migration between the older bad-behaving version and the newer vista-compatible version, and there's a huge users pool that the developpers want to avoid pissing because of a non-trivial migration.
- And finally, they aren't compelled to change this, because users are running with UAC disabled anyway.
The last solution would be
- VIRTUALIZE IT. Put all old-world (pre-Vista) software in a sandbox, a chroot jail, or whatever it is called in Windows. Whenever some pre-Vista software tries to access stuff it shouldn't in a normal user context, just do it - but on a dummy local copy to both avoid damaging the system and avoid annoying the user. That's the route that Apple has went were pre-OSX apps are ran inside some kind of emulator. But that is easier for them because of the radical shift in architecture : older software rely on a such different API, that it had to be emulated anyway, throwing a sandbox in the mix was only an added bonus.
Microsoft could do it as easily, because, fundamentally, Vista is XP with a shiny interface and some DRM thrown in. It would have annoyed users : They used to ran perfectly well behaving software writen for NT-Kernel under XP and suddenly, under Vista which uses mostly the same internal structure they have to run the same software inside a sandbox.
Microsoft SHOULD have spent a lot of time planning well the transit
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
There is a simpler solution: virtualize the O/S for users. Let users play their own version of the O/S, but without a problem for the other users.
Microsoft should have done that right from the start, because their O/S was single user from the beginning.
Another idea is that of protection rings, similar to 80x86 architecture: let each system resource belong in a ring, and allow access to resources only from privileged rings; access less privileged rings only through secure predefined gates. The nice thing with this is that, since it is implemented in software, there is no restriction to the number of rings available.
With this approach, applications that receive data from the network could run at a higher ring from the rest of the applications, and thus they could never touch user data (let alone kernel data).
IF developers would program their programs right we wouldnt have this problem. If they made something like a game install without having to be an admin then we wouldnt be having these problems. By this I mean. Why does a game have to install registry files? Why cant they be stored in say an encrypted file in the games directory. Even if microsoft changed to unix we would still have these problems because its the developers who refuse to change. Developers should start doing things the right way and start making thier programs not have to be installed into system critical areas.
Microsoft did not invent sudo. They are the absolute last of the pack to implement it.
It's been optional to use forever. Restricted environments (where users still need to work, save files, etc) have been running in NT domains configured to disallow system modification forever and a decade. Vista's been in beta forever, and you need to have been on the friggin moon to not have known well in advance UAC is coming.
If your software writes outside your profile without a very good reason to do so, either update it, or smack the vendor on the head, because it is absolutely his fault. Just because it was ok to do something a certain way in the past doesn't make it ok to do it that way today. UAC/sudo is a simple Darwinian evolutionary step, a trait that gives advantage in a specific environment (The Internet a-la 2007) and is thus selected for, appearing in the next generation of the microsoft OS.
Blaming microsoft for it is lame (Unless you're blaming them for not having done it when Windows 2000 came out, that's ok.). They didn't do any foul play this time. Some developers having issues coping with the "new" reality? Market forces will take care of them soon enough, nothing to get concerned about.
-
developers are lazy and sloppy.
It's not just Windows developers running as admin. It's C programmers using sprintf. It's java programmers catching all throwables. It's web programmers taking some string of unknown origins and handing it to a SQL interpreter connected as an account that has DML privs.
What makes a difference is consumers. Unix users don't accept programs that run as root. MacOS users get somewhat better UIs because they demand it. Windows users use Windows because they feel they have to, and so anything goes.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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
Windows NT has been out for well over 10 years now and has ALWAYS been a multi-user OS. Windows NT4 was the first really user-friendly version of NT and was the version I started using and never looked back. Developers NEVER coded apps with this in mind, they were too busy hacking together apps to run on Windows 95 and if they worked on NT great. I'm not talking about little utilities or games here either. Photoshop, Office, 3DS Studio MAX, you name it, none of them took into account the security features of NT or the fact that one can run NT in a non-Administrator mode. UAC is not the best answer from a security standpoitn but it is a way for Microsoft to prod developers to think about users when they develop apps for Vista. Windows 95 and its progeny are long since dead (some users just haven't figured that out yet - you know who you are *Windows 98 users - cough*) and the NT based OSes are the future of Windows. Developers now need to work with what they have and stop being lazy.
The linked article laments running as "admin" on windows and offers a few possibilities why it is done that way and why developers feel the need to do it that way.
But it forgets the single biggest reason why it is done that way in the windows world on a regular basis. Before the advent of NT/XP, windows had no concept of "users" as in the Unix plural users sense. There was only one "user" in the whole world from it's perspective, that user sitting at the keyboard/screen/mouse, and that person could do anything they wanted anywhere they wanted anytime they wanted to the system. This was an outgrowth of the fact that windows started out from the DOS world (where you ran as "the all powerful" all the time as well). and only very very recently was drug, kicking and screaming, into the real world of needing an "admin" to modify critical system stuff, and running as a normal "user" the rest of the time. So, yes, the linked article is partly correct, in that developers who write presuming that everyone ins "admin" are part of the problem, but they are only following the lead set out by microsoft.
So the proper blame lies squarely with microsoft, for spending 20+ years "programming" people that 1) it should be mormal that your computer crash 2-3 times a day, and require 5 reboots unrelated to the crashes, and require additional rebooting to make almost any system change at all, and 2) it should be normal to be the all powerful "admin" all the time on your computer.
The blame lies with microsoft producing a system that works that way. The developers were just playing follow the leader.
Since they were creating something "new" anyway, why not base your model off of something that actually works, like OpenBSD's systrace, instead of just trying to annoy the user into turning off all security notifications?
A definition file (could be supplied with the program) defines what it can do and can't do, and what specific operations require enhanced privileges. At installation time, this definition file could even be pre-inspected, and warnings flagged if it appears to grant too many privileges. If a program tries to execute an operation in a way that it's not specifically allowed to use it, it's denied and an error is flagged. They already have sudo, er, "run as", for legacy applications if the user still has some lingering around.
It wouldn't change much, because the users themselves need to actually care and to be educated about using a computer wisely and securely, but those who did care and wanted to try would be MUCH safer with that than anything Microsoft has ever released.
Oh, wait, I know why they didn't do this. Then they couldn't (secretly) backdoor your computer as easily and sell backdoor landscape to spyware companies (ie: Sony, etc). Nevermind.
-M
I'm a developer and I have it off, but it's the ONLY way to run the compiler in Wow emulation mode on a 64 bit operating system. So...
So, your answer would be to get rid of all browser plugins, period? No more Flash? No more Java? No more QuickTime? All of these involve third-party code running in a native process space which could be compromised. All the user has to do is click "Yes" and that Java applet can start rampaging through the system, trashing the user's profile. UNIX, Windows, Mac, doesn't matter.
Why stop there? Why not get rid of pictures, too? Afterall, Linux, Mac and Windows all had vulnerabilities at points in time in reading PNGs. Can't always anticipate buffer overflows, so might as well avoid them.
Or maybe, just maybe, you could borrow a page from OpenBSD and load the browser into a jailed process which sandboxes the entire browser, plugins and all. Only way out is through a security broker with only a handful of specific targets. A buffer overflow in a third-party plugin wouldn't even allow the malicious code to trash the user's profile, let alone the rest of the system. And on top of that, just in case, also wrap the process in a constrained user token, so that even the broker itself is limited to only functioning at the strictest of user settings. This way you'd have to have at least 2 vulnerabilities to manage an exploit, and 3 to actually do any damage.
Oh wait, that is what IE7 on Vista does.
putting data in HKLM (HKey_Local_Machine) when it doesn't need to be, is bad. HKCU (HKey_Current_User) does not require Admin Priveleges, nor does it bring up a UAC Prompt.
Contrary to what a few mindless Linux zealots will tell you, Windows NT has always been an isolating multi-user system. That is, multiple users are supported, and each user's data is protected from other users, as well as system data (all the stuff outside the users' home directories). Always. However, NT's backward compatibility wasn't so good at first, particularly with 16-bit programs. As as result, even though it was relatively stable and secure, it was pretty rare for quite a few years.
The admin problem really comes about with Windows 9x, which was released a couple years after Windows NT. Windows 9x is not an isolating multi-user system; in fact, it basically has "multi-user" capabilities strapped on to Windows 3.1. There's no file system or registry permissions, nor is there a distinction between admin and vanilla user. Windows 9x quickly became popular, as it had fairly good backward compatibility with DOS and Windows 3.1 programs, and was significantly better than Windows 3.1 in general (though nowhere near comparable to NT). So, developers everywhere started writing programs for Windows 9x. Most of these programs didn't need to run on NT (as it was a niche market for some 7 years after release), so they didn't. Dealing with limited access was more difficult, and programmers were lazy.
Consequently, by the time NT finally overthrew 9x (with Windows XP), you had a huge number of existing programs that assumed full access of the computer (for one particularly bad example, the Mechwarrior: 2 Mercenaries installer used CLI and STI for something or other - kernel mode instructions; this blew up very badly on NT, so I did some debugging). But much worse, you had an entire generation of programmers that didn't know how to work with limited user. And since most users were forced to run in admin so that they could run legacy programs in XP, the developers figured that they didn't need to learn, and the problem became self-perpetuating.
In conclusion, YES, developers are 100% to blame for the admin problem. Granted some of those developers are in MS, but in general I've found MS programs to work FAR better than third-party programs, with regard to requiring admin. I'm speaking as someone who has been running as limited user for several years and runs MS programs like Visual Studio and Office very frequently.
As a footnote, I really wish NT offered a service to allow programs to temporarily elevate their privileges (such as getting write access to their program directory) to install patches without requiring admin (once the service verifies that the patches are properly signed). Myself and a friend are considering making such a service ourselves, actually.
You have tried to support your argument with faulty reasoning! Go directly to jail; do not pass Go, do not collect $200!
Actually, Vista does virtualize SOME attempts to write to Program Files and HKLM. In fact this was one of the touted features (the writes get redirected to user-specific areas).
First off, I agree with the article's assessment that it is the developer's fault why UAC is required in the first part. Now, I know this is slashdot, and Micro$oft bashing is everyone's favorite past time here, but, I'm going to defend them for a moment. The reason why I say it's the developers fault is because for YEARS Microsoft has been publishing information on how application's should function to work in as "Limited Users" (aka non-Administrators), at least since the days of Windows 2000. Now, the problem is, most developers I know have never even heard of this! What is this magical mystical document I speak of? Well, it's the Microsoft Logo specifications, aka "Designed for Windows". This talks about all kinds of useful things including separation of user data from application resources; which from my experience is the primary reason why USER applications do not function as non-Administrators.
t a/getstartedcert.aspx?LangType=4105
9 29d-679a-4238-8c21-2dcc8ed1f35c/Windows%20Vista%20 Software%20Logo%20Spec%201.1.doc
Now, I also know that Microsoft themselves haven't followed their own rules, and some applications still require administrative rights (and some stupid design decisions such as IE's Code Store Database). Combine that with the fact that they have to support an existing installation base of applications that don't follow those practices and what else can they do? Ever tell have to tell a business user that they can't use their mission critical application anymore because it doesn't work with a proper security implementation? How about telling a Grandparent that have to go buy a new version of some application that they've been using for 10 years because it doesn't work on their new PC? UAC is Microsoft's bridge to go from the old way of everyone running as Admins to the way everyone else has been saying to run, as a "Limited User". It's either that or the proliferation of the fallacy that on Windows you must run as Root.
So, UAC sucks, but can anyone actually recommend a better solution that will work for the install base Windows has? I'm not talking about the "Windows has more users than Unix/Linux/Mac", I'm say that Windows user's and developers are DUMBER than Unix/Linux/Mac users/developers. Now, don't get me wrong, there are extemes on both sides of the fence, but if we looked at percentages, the percentage of dumb users and developers on the Windows side will probably far outweigh those on the other platforms. (Queue the "well switch stupid" comments. And I will, once the industry does as well, it's all about critical mass people.)
Here's some more information on the Vista Logo requirements:
http://microsoft.mrmpslc.com/InnovateOnWindowsVis
Here's the "Requirements for the Windows Vista Logo Program for Software document":
http://download.microsoft.com/download/8/e/4/8e4c
of old and new features, deprecated and new APIs, etc... I'm amazed any developer can keep enough of it in their head to write a well behaved application on Windows. Oh, wait... there are some, aren't there?
Many developers were no doubt spending far too much time converting all their string calls to *_s "safe" versions or for 16 bit characters to get around to figuring out what they need to do for UAC. Either that or they just turned UAC and all the compiler warnings off and are completely oblivious to what they're doing wrong...
If Windows wasn't such a rats nest of work-arounds and redesigns, applications would be far more stable and well behaved-- and even Microsoft often can't seem to follow their own rules. The "virtualization" of "program files" and the registry is an ad-hoc kludge if I ever saw one, just one more convoluted whacky factor to mess things up. Oh yeah, it works great-- transparent until you start working with backup programs or migrating or replicating users or user configurations.
Yes, developers do need to use better practices. I sincerely wish they'd remove the registry except for actual system settings (use an XML configuration file, which you can actually *validate*, and keep it in your application directory, dammit).
But UAC seems like it won't do much but annoy people into using it. I mean, if you were spyware, even though it's training folks to ignore meaningless, endless security dialogs with NO useful information, wouldn't you turn off UAC (and the warnings about not using UAC) first thing?
Besides, Microsoft ought to take its own advice. If you use the Control Panels much, you get plenty of ridiculous warnings. Maybe they need to practice what they preach instead of shifting the blame onto everyone else, then telling all the other OSes that they should infringe upon Microsoft's patents on this worthless, annoying piece of crap known as UAC?
I swear, they must have Paula Bean working for them. You want a better option? DENY permission to do Bad Stuff[TM] by default, and force the user to set permissions manually if they don't like that (i.e. don't make an API for it). If developers had to choose between a 10 page manual telling the user to toggle permissions to 80 different files and making their application use better procedures, they'd still have to choose the latter, and you wouldn't train people to ignore "security" warnings in the mean time!
Always worked nice in AmigaOS so why not. Copy it to your system partition if you want to or don't, in any case it will work. If you ever had to do anything it was an assing (say assign firefox: dh1:apps/firefox) for applications not hardware drive aware which looked for their device name.
Start with Ubuntu, then complete the wine implementation of the windows api. Drop their proprietary networking protocols and use Samba as base to port their functionality. Rebrand it all for MS. Beyond that, security problems are on the users.
So, your answer would be to get rid of all browser plugins, period?
Now why would I point to Internet Explorer specifically if I were proposing getting rid of all browser plugins?
Think it through, do a bit of research, and try and figure out what it is about ActiveX that makes it so much more dangerous than Java, Flash, Quicktime, or other plugins that don't include a malware-empowerment API as an integral part of the design. Hint: fixing a buffer overflow doesn't break working APIs.
load the browser into a jailed process which sandboxes the entire browser
That would keep malware from trashing the p0rn collection on your hard disk, but it wouldn't do anything to keep the malware from taking part in a zombie network or forwarding your credit card info, bank account and paypal passwords, and other personal information through the zombie network to the attacker.
Once the browser's compromised, the attacker has won half the prizes on the table. Keeping them from making a clean sweep of it is a good thing, but it's no replacement for getting rid of inherently infixable and insecure APIs.
In 1997, under the Win95/98 model, there was no significant administrator vs. user account. In fact, I don't recall multiple accounts per machine. They finally added an administrator account and user account distinction that was easily accessible, and you blame the Office developers for not anticipating what the OS team would do??
I do agree with most of your registry bashing however.
Your ad here. Ask me how!
It's way to late now of course, but...
Windows NT 3.x should have mapped C: to the user's home directory. Each user gets their own WINDOWS directory.
Windows 95 should have made the non-user portions of the registry be read-only or even missing.
Then the apps written for Windows 95 would run within the user account. Those without drivers would have been fully compatible with Windows NT 4. Non-hardware drivers could have been virtualized in the next release.
OS X works hte way you want. You should try it, you might like it. I now have two Apple computers...
Your Average Joe
Autodesk has the monopoly on the 2d cad market, they also have the Windows logo on the box.
Guess what? AutoCAD requires the user to be local admin. THey make no bones about it. THis is what you get when you have two monopolies writing software.
Your Average Joe
In the 3rd to last paragraph, a sentense should read "There must also be utility to manage read-only access RIGHTS, whereby a user can TEMPORARILY GRANT read-only access to files or folders to a specific application. This model promotes organization, good backup habits, and PREVENTS accidental overwriting of archived files simply by wanting to save your work."