Vista's Troublesome UAC is Developer's Fault? 228
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?
I saw a different problem (Score:3, Informative)
- 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 justRe:I saw a different problem (Score:5, Informative)
Which goes to exactly what Ian was saying -- If you're really seeing UAC that often, you're doing something wrong (or you're using software from developers who did something wrong). As developers get their act together and stop requiring admin privileges for trivial things (hint: using %userprofile% and HKCU rather than %programfiles% and HKLM will solve 90% of your admin-privilege requirements when developing), UAC prompts should appear less and less often, and then only when you really expect them (you're doing system configuration stuff) or when there's a real issue that you should deny. Unfortunately, that world is probably 3+ years away as developers get with the program and rev their software, and in the meantime UAC will just become one more annoying dialog you have to click through to do anything.
With that said, I saw the UAC dialog exactly once today, and that was only because I had to upgrade my video drivers. I'm a professional software developer. I spend my time with Visual Studio and SQL Server, and I rarely have to deal with UAC prompts.
Re: (Score:2, Interesting)
* Today I ran across a stack class that used for its push function... an overloaded operator new...
Re: (Score:3, Funny)
(Please do note that I'm not defending this decision, just pointing out what the thought process likely was...)
Re:I saw a different problem (Score:4, Insightful)
Who is a developer supposed to listen to -- Microsoft or Ian Griffiths? It seems to me that Griffiths has a lot of nerve blaming developers for following Microsoft's recommendations.
Re:I saw a different problem (Score:5, Informative)
Re: (Score:2)
If attaching to a process to debug it doesn't require admin privileges, Vista has a lot more wrong with it than the annoying UAC giving false positives...
There are some scenarios that require this, but they're generally the exception rather than the rule.
Debugging most certainly does not count as an exception to the norm. If you need to work with someone else's code, walking through it a few times with a debugger will teach you more in one d
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Of course, you could use SELinux and its application roles. That might help.
Re: (Score:3, Insightful)
Beside that, running a debugger is also far from the easiest way to get someone's passwords if you have the ability to launch programs.
Re: (Score:2)
Re: (Score:2)
Maybe it's his signature? Does he really need to tell everyone he works for Microsoft? Can't you just provide good information and not bring the company you work for in to try to up your "cred"? I mean, most of us work for some IT firm or company that many have probably heard about, but when you resort to using the name of some other entity to further your goals, it seems a bit self-indulging.
That and many of us don't particularly care for Microsoft and their
Re: (Score:2, Insightful)
Maybe it's his signature? Does he really need to tell everyone he works for Microsoft? Can't you just provide good information and not bring the company you work for in to try to up your "cred"?
However little I care for Microsoft and their business methods, I prefer that he has a disclaimer - otherwise someone would probably troll over his repeated MS-related posts (which I've seen countless times here when people have had repeated good things to say about X company).
Also, apart from that, Microsoft is a very visible and controversial company, so owning up to being part of it is fine (in my book). That gives you a chance to weigh that onto what he has written and evaluate it in that context.
Whe
Re: (Score:3, Insightful)
Re: (Score:2)
Heh. And Ubuntu users have a lot of nerve blaming me for following the install CD's HIGH RECOMMENDATION to install grub on the MBR.
Re: (Score:3, Interesting)
So it's a matter of perspective. I will agree that if I had to keep most other programs open to avoid the UAC, it'd be annoying.
(I don't have Vista yet... I'm waiting for that first killer game that makes it a necessity.
Re: (Score:2)
Currently open on my desktop:
Harvest (source control) - opened for two weeks now
Eclipse (Java) - opened for 4 days
PL/SQL Developer (Oracle database) - three copies (each to a different database) 2 to 9 days
WebLogic (hosts the Java) - restarted yesterday because I changed the JDBC pool
There's a required patch that I have to install today, so obviously those numbers will reset.....but I get more work done not waiting for things to start.
Layne
Re: (Score:2)
Re: (Score:2)
Except that using HKCU has another problem: many programs register stuff they need in the registry. On a single-user system HKCU isn't a problem. But when another user tries to use that installed program, BAM, none of the required registry entries are in their HKCU tree. Which means developers have to develop another set of practices as well: either writing programs that can self-register themselves and set up all the neccesary registry entries on their own independently of the installer (at which point the
Re: (Score:3, Interesting)
Re:I saw a different problem (Score:5, Insightful)
That's not fair, to expect Office 97 to run fine on Vista. Well actually it is. If you had followed all of Microsoft's best practices, and work the platform as designed....you end up right where we are at today.
Were Microsoft programs ever written to be run as a low privileged user working only with the users folder in "Documents and Settings" and only writing to HKCU. With the installer designed to be run once as an Administrator to write files to "Program Files" and HKLM?
Yes, you could always run a low privileged account and change permissions on certain registry keys. But face it, these are a hack. Until recently, Microsoft never wrote software that way. They never seriously advocated it either. If they did, professional software such as Quickbooks 2001 or 2005 would run just fine on Vista.
Hell, the whole registry thing was a bad idea. In the Linux world, when you move to a new box, you can copy an rc file or folder from /etc and your rc file from your home directory and the program is configured to run properly on the new machine. Bash_rc for example. Most well behaved programs make few if any changes to other programs rc files. Very few of those even need any files from /etc, usually just one file or folder from your user directory is enough.
Most of the time in Windows you can not even copy out the relevant section from HKLM and HKCU because of the shoddy programing practices as taught and evangelized by Microsoft. So many entries in the registry are spread out over so many places, the program won't run if you copy just one section from the registry. A good example is Outlook Express. You cant just copy out "Outlook Express" keys from HKCU and the data files and expect it to run.
If I had to point my finger at developers for bad practices. I will be pointing my finger towards Redmond Washington.
Re:I saw a different problem (Score:5, Insightful)
Re: (Score:3, Interesting)
Re: (Score:2)
Microsoft teaches programmers how to get up to speed and write something in windows. Security is not even tacked on as an afterthought.
If you just "drop" the data file on the new machine, you still don't have any information about the POP account, or passwords. Trust me, when you move that stuff for so
Waiting PASSIVELY is not a good solution. (Score:5, Insightful)
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
Vista does virtualize (Score:2)
Re: (Score:2)
Uhmmm, yeah. On a blank, brand new Vista install, no 3rd party apps the $!#%ing UAC thin
Re: (Score:2)
You can't install software on a user, so anything a program needs to be successfully run after being installed needs to be HKLM.
Now, user preferences etc. should be HKCU, because tho
Re: (Score:2)
Its easy to blame developers but Microsoft has created this problem as much as anyone. There is very little available in terms of best practice guidelines for developing on windows and there really never has been. Developers learned mostly from the behavior of MS applications and from what was the easiest way to develop applications. UAC isn't that much different from the privlage escalation stuff on the mac but you dont see that dialog come up very much. A lot of this comes from the architecture of the
Re: (Score:2)
Yes. As a Vista user I recommend just disabling the stupid thing.
No chicken and the Egg problem here. (Score:4, Insightful)
Re: (Score:2)
You the have trust in the competancy of the developers that it will allocate the resources it needs then suid to a lower priveleged user.
Admittedly thats 2 parts - one the OS being designed to let you do that.
Two, having decent developers with well tested products - I know you wont have an issue running apache as root and letting it suid - but how about some unknown piece of software you have never heard of? Will you just run it as root without thinking? Probabl
Re: (Score:2)
ian
I kinda like the concept (Score:5, Insightful)
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.
Re: (Score:2, Informative)
Just for the record, you don't have to stay out of the registry if you want to avoid admin privileges.
Re:I kinda like the concept (Score:4, Informative)
I really hate to say this, but this is very similar to how Mac OS X works most of the time. Most programs are installed by dragging the icon into the Apps folder, and most programs are uninstalled by deleting them.
Configuration files are a little more complicated, but transferring all the user settings is very easy too, there is a transfer agent that allows you to copy your apps, files and settings to another computer. I know Windows has a transfer agent, I just used it today, and unfortunately, the Windows transfer agent isn't nearly as good. A lot of the preference settings do transfer if you just copy the Library folder in your home directory, system settings are in
Re: (Score:2)
A bit of ridicule (Score:4, Interesting)
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.
Re: (Score:2)
OT I know! But drawing attention to Creative's unethical practices can never be a bad thing.
Gentle Reminder... (Score:3, Informative)
PROMPT $p$g
C:
CD \NWCLIENT
SET NWLANGUAGE=ENGLISH
loadhigh LSL
loadhigh NE2000
loadhigh IPXODI
VLM
CD \
Re: (Score:2)
Re: (Score:2)
Modern systems are just too complicated for that. If you've got multiple users, the configuration is going to be scattered around. If it runs as a daemon or has shell hooks, it has to go somewhere too. If your program has any dependencies, it's going to have to install a shared library (DLL
Re: (Score:2)
On the other hand, if it's a DLL that is used by several applications, then this one app has no real business installing it in the Windows directory and especially not overwriting an existing copy of the same library (even with a newer version). There should be a separate package for the library which manages the library's files, and which can be marked as a dependency by any application that wan
Re: (Score:2)
Re: (Score:3, Informative)
Granted, some crap comes with a windos-like "installer", but on OSX you actually "install" most programs by drag&drop to the applications folder, and you uninstall them by drag&drop from applications to trash.
Re: (Score:3, Informative)
The problem with the OS X method is that it can't differentiate between removing because you are uninstalling and removing because you are upgrading. It would be nice if the user defaults system did some kind of auto-cleaning, where defaults created by progra
Re: (Score:2)
So, you need to put the 'static' program apps and so in
If they were the 2/3 places you could find an app's files then I think that'd be fine.
Re: (Score:2, Informative)
Re: (Score:2, Insightful)
Now you're kidding. Please explain how do I remove Apache by removing a single directory? Or even something simpler, say, vi?
Re: (Score:2)
remove:
then find out where the per-domain configuration has ended up being stored and delete those.
Of course the above only applies to certain Linux distros, others will put their apache (which may or may not even be called httpd) in different directories.
Re: (Score:2)
Note: don't.
Re: (Score:2)
Re: (Score:2)
Admin-level privileges (Score:5, Interesting)
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.
Re: (Score:2, Funny)
Nope. Can't see it happening.
Making a statement (Score:2)
Re: (Score:2, Insightful)
In theory, that already exists [msdn.com]. In order to use the "Certified for Windows Vista" logo on your software, you have to play nicely with UAC.
Re: (Score:2, Interesting)
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.
That is actually THE first requirement listed in the Certified for Windows Vista Logo Technical Requirements [microsoft.com]
Re: (Score:2)
I think it is a carry-over of the 16 bit Windows compatibility though, from the 9x series to NT series Windows. For 9X, there were no security considerations like this, and for NT series, compatibility seemed to require admin rights, and developers didn't change their programming practices because they didn't have to.
Re: (Score:2)
Yeah, it wouldn't help anyone who's not developing in Visual Studio, and it wouldn't help anyone at this point who neglected to patch their copy of VS. But at least it would provide helpfu
Re: (Score:3, Insightful)
That's great and all, but they already do something similar. Ever see a shrink-wrapped box at the store with the "Designed for Windows" logo on it? Part of the logo testing is t
The security model is all wrong.. (Score:5, Interesting)
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.
Won't work (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
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.
Re: (Score:2)
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.
Bingo!
Where is my "run this program but don't give it access to any of my data" option? That is something I want and that users will understand. Explicitly granting permission to syscall 0x6f03a4b loopback technobabble nonsense does not and never will fly with users who feel more intimidated than protected. Granting "permission to accept your personal data" is more like it. So run everything in a sandbox unless I explicitly allow it to read my files. Once. Because we all know that if I've given root/user/w
A simpler solution exists. (Score:2)
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 wit
Re: (Score:2)
virtualize the O/S for users. Let users play their own version of the O/S, but without a problem for the other users.
This is almost what UNIX does (and what Plan 9, which is more UNIX than UNIX, actually does). The problem is that it protects users from other users, but it doesn't protect users from malicious applications.
In an ideal world, all software would be run using the principle of least privilege. My web browser would be able to link to the libraries it needs, read and write to a configuration file / folder, and write files into a downloads directory. You can do this fairly easily on a modern *NIX using som
Re: (Score:3, Informative)
That would be called SELinux and is turned on in Fedora Core.
Writing policy files either as a user, admin or even developer is hellishly difficult. FC has been messing with SELinux policies for years before getting it right. It almost requires an interactive mode where the policy can be "trained" by running the app a multiple times to see what registry / folder / files i
Re: (Score:2)
It's not fully "user friendly" yet (it was originally designed around group policies in a corporate environment), but newer versions of
They're half-right (Score:3, Insightful)
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.
Re: (Score:2)
Re:They're half-right (Score:5, Interesting)
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)?
Re: (Score:2)
Yes, that's true. This was also the time when Microsoft didn't give a rat's ass about security. Unfortunately they kept getting raked over the coals for having glaring security holes, so they are focusing more on creating an environment that is/can be/should be more secure, and as a result developers who've been able to code howeve
Re: (Score:2)
Sadly, this is so true. Also, when the vendor out-and-out lies about these issues to make the sale. Lesson learned - if it isn't in the contract, anything the vendor told you means jack.
Re: (Score:2)
They did.
NT domains running environments where users are not trusted and do not have permissions to modify the system have been around for over a decade. That was also roughly when the windows equivalent of
Microsoft software has been properly using these for all this time, setting proper example.
Vista was in beta forever. Any software vendor that was caught by surprise by the instatement of UAC shoul
UAC is good - if you understand it! (Score:5, Interesting)
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
I like UAC, personally (Score:4, Interesting)
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.
Another non-issue (Score:5, Interesting)
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.
Re: (Score:2)
Because they're morons, don't/can't/won't understand and/or simply don't care, they just want it to work, now, no matter what the consequences. When it stops working they'll call the 10 year old kid next door or get a new computer.
OTOH,
That's the problem: most Windows systems are still single (physical) user machines; they don't have (half-)clued in admins to manage them on the user'
Re: (Score:2)
- Not leaving ports open unless they absolutely need to be
- Not running Outlook Express and randomly downloaded crapware
- Using a reasonably secure browser, and avoiding popup-infested porn and warez sites
- Not running britney_spears.exe when it arrives in your inbox
A secure permissions model has very little to do with it, IMHO.
UAC is generally a good thing. (Score:3, Insightful)
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.
Why is Microsoft asking questions on Slahsdot? (Score:2)
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
Re: (Score:2)
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.
Should we not help Microsoft developers, just because this is Slashdot?
Some people are interested in the problem and in how to fix it. Believe it or not, some people actually like Windows.
I'm certainly not one of those people; I've been using Ubuntu for two years. I'm just saying, they exist, hence the question. Besides, even if we're not Windows users, most of us would like to see Windows more secure; everyone would benefit from having less botnets around.
Re: (Score:2)
Please read my post in full. Every single Microsoft developer knows, or definitely ought to know... that UAC is a piece of junk. The insecurity with Windows is inherent.... the OS, or Microsft or Bill Gates.. ow whoever made that design decision... think that they own YOUR computer. It is impossible to secure the operating system as long as this fundamental issue is resolved.
Since this is a design decision taken at the very highest level
Re: (Score:3, Insightful)
I don't think Microsoft are asking. I wrote the blog entry the question refers to, and I don't work for Microsoft, nor was I acting on their behalf. (And I don't imagine I've made myself any friends in Microsoft with that blog entry.) I know the guy who submitted the question to Ask /. (MythMoth) - he doesn't work for Microsoft either. In fact as far as I know he mainly runs Ubuntu these days, and he's been a Java developer for years.
My motivation is pretty simple: I think it sucks that lots of apps have
Re: (Score:2)
Thanks for taking the time to post a rejoinder. My query wasn't on your i
Re: (Score:2)
Wow, that's not even slightly close to a good example of what you
Historical problem (Score:4, Interesting)
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
UAC is cosmetics (Score:5, Insightful)
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.
It IS the developer's fault (Score:2)
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
News flash (Score:2)
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
1. UAC is not SUDO. 2. What they did wrong. (Score:4, Interesting)
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
I do blame developers (Score:2)
Re: (Score:2)
I've been saying this for years. It all stems from MS-DOS. There, you could put anything anywhere, and nothing cared. Then the DOS developers moved to Windows, and kept the habit. Then Windows went multi-user, and suddenly stuff started breaking.
So the user calls the vendor for help. Support calls cost money. So the vendor takes the quick way out and tells people to run as Administrator. Program runs now, so the problem appears to be fixed.
And to be fair, I've been guilty of this myself.
But so have o
A Brief History of the Admin Problem (Score:4, Insightful)
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.
Re: (Score:2)
I'm somewhat conflicted about the registry. On the one hand, it prevents the practice of scattering configuration files through all corners of a hierarchical filesystem... on the other hand, it does this by telling people to scatter configuration data through all corners of a hierarchical
While the problem of configuration is not solved by the registry, I think it's at least superior to
Re: (Score:2)
So you blame developers for following Microsoft guidelines?
Microsoft dictates that Windows programs (games, utilities, etc), write to the registry. Its part of the "Windows Certification" process. You should be asking yourself why Microsoft didn't allow
Writing to the registry is fine... (Score:2)