Slashdot Mirror
Microsoft Caves, Will Change UAC In Windows 7
CWmike writes "Reacting to intense criticism of an important security feature in Windows 7 (which we discussed a few days back), Microsoft today said it will change the behavior of User Account Control in Windows 7's release candidate. In a blog post, two Microsoft executives responsible for Windows development, John DeVaan and Steven Sinofsky, said 'We are going to deliver two changes to the Release Candidate that we'll all see. First, the UAC control panel will run in a high integrity process, which requires elevation. Second, changing the level of the UAC will also prompt for confirmation.' They said the changes were prompted by feedback from users, including comments on an earlier post Thursday by DeVaan in which he defended the modifications Microsoft made to UAC in Windows 7."
Intense criticism? Define "intense."
Isn't this how it's supposed to work? Release pre-production code to the community. Listen to comments. Respond to comments as appropriate.
Now define "over the top."
With the initial Vista UAC people were trained to just click yes to everything or they would turn off the function entirely. With Windows 7 it is far less frustrating but the User part of the UAC is what is broken, there is no substitution for actually educating users. That is something that is far out of MS's reach IMHO.
The pain threshold, it turned out, was just two prompts in a session, which DeVaan defined as the time from turning the PC on to turning it off, or a day, whichever is shorter. "If people see more than two prompts in a session they feel that the prompts are irritating and interfering with their use of the computer," DeVaan said.
I get asked for my password when I do something in terminal that requires sudo, but other than that, I don't get a security prompt more than once a day on the average. Again depending on what I'm doing. I can go an entire day and not see one sometime.
I suppose I'd like to spend a day watching a windows7 user and see WHY they are getting all these UAC popups. I can't believe that if the OS is engineered properly if there would be any reason for it with ANY frequency unless you're doing things that *I* might find common, which is not Joe User.
I have my mother's main account on her machine as a limited user, and she knows the admin l/p when needed. I bet she gets asked for it once every 2 weeks at most. (like when a firefox update wants to install, and then it's behaving exactly as expected and desired) THAT'S how I'd expect ALL "typical" computer users to want to see. I'm absolutely certain I'd be getting a phonecall after she got prompt number two (for no good reason) in the same day. Why does it keep doing that? Fix it!
I work for the Department of Redundancy Department.
This is hardly "caving". Microsoft was alerted to a security issue, and they're fixing it. How did this get spun into an anti-microsoft story?
Did I miss some story where Microsoft said they absolutely refused to fix the problem, but now a few days later they're giving in and fixing it?
Um. You're aware the access controls of the Windows NT line is MORE fine grained than UNIX, right? The entire reason SELinux was created was to give Linux the same granularity of Windows, so the NSA could use it internally. So, I would say Windows has proper account permissions. Even if 99.95% of all users misuse them.
When I read the headline...that they were going to implement proper user account permissions (a la UNIX) so UAC wouldn't be needed. Alas, I was disappointed.
By that you mean "put password in everytime you need to elevate?". UAC does that if you're not an admin. If you are, because you're not really an admin, it just confirms you want to...if the app is digitally signed; if not, it give you a big scary warning box you actually have to read.
throw new NoSignatureException();
There was an article a while back about some application programmer complaining about the security model in Vista and what a pain it was to develop for.
What it actually came down to was the programmer was complaining about having to separate privileged code from non-privileged code.
Just about every app made for Windows run in admin mode and UAC will complain about it.
In *nix it would be like requiring root to run the tar or ls commands.
the one thing that will make me consider not turning it off. A "do not ask again for this application" checkbox.
Come on. Every firewall/HIPS system I can remember trying the past decade or so has an option to remember the answer.
This obviously won't work for settings, but for when starting an application? God, it's so needed.
While many may scoff at UAC, it does do something very well. It foists responsibility on the user. While this may not be the nicest thing to do, it enforces perhaps the most difficult ideal. That being of awareness of security. User that have no idea, will not be aware of how to protect themselves. Perhaps I am being too forgiving but perhaps someone in Microsoft has actually come up with the philosophical crux of security argument in that no matter how well you design a system, no mater how many updates, patches, or how secure a system you make, someone at some point is going to break it. If DRM, or adware, malware, virus, or Trojans have taught us anything, is that no matter our perceived security we are all vulnerable at some level and all that it takes is someone willing to go the distance and break it. I think microsoft would be correct in its thinking that they will always be target #1, and for the foreseeable. That said, how do you protect yourself from all the bad guys in the world. Well you could create some wonderbar new technology that will secure your systems, and update it constantly to try and keep up with attacks, knowing that it will eventually fail. Or you can implement that and make your users aware of basic security issues, which would probably be about a thousand times more useful as most of the time these things happen when a stupid user opens a file he shouldn't or downloads something sketchy, etc...
I mean when you hose your box you have no one to blame but yourself. Usually it become apparent shortly after you tell UAC to go screw itself. Then you know. Now in the future when you download that mp3 and try to open it with media player, which doesn't reconize the file type, you might actually think. "Ok this may be a codec it doesn't know, or it is a very bad idea to get it to try and open it anyway, perhaps I will just update my codecs and see what happens".
Anyway I am sure some security professional (both IT and otherwise) will attest to having a user informed and aware of potential threats is far more useful than anything else.
Of course perhaps I am just giving Microsoft too much credit.
the uac model is inherently broken.
Citation needed. Along with suggestions on a better alternative.
This space for rent.
No... SELinux goes way beyond the access controls Windows NT has.
What you're thinking of is basically the POSIX ACLs. They've been in Linux for years. They don't see much use, because in the vast majority of cases, the old Unix permissions are good enough, and much easier to manage.
You have the standard owner, group, and everybody permissions on each file. If a file also has an ACL, it takes precedence.
Both Unix permissions and POSIX ACLs, as well as Windows's permissions, are a form of user access control.
SELinux is something else entirely - it's a form of mandatory access control, and it's applied to applications instead of users. A SELinux profile defines what an application is allowed to do - which system calls it may use, what files it has access to, and so on. This runs alongside the Unix permissions.
The closest analog in Windows is IE7's Protected Mode, where IE7 (and only IE7) is sandboxed and is unable to access anything but it's own configuration files. It's not really the same thing though - it's a sandbox, not a MAC implementation. A MAC implementation can be used to build a sandbox, but it can also be used to do far more.
It's not there to prevent users from doing something stupid. It's there to prevent applications from doing something they aren't allowed to, so that in the event of a security breach, an attacker is prevented from doing anything the application wouldn't normally do.
SELinux is not about account permissions. It is based on security contexts which may or may not involve user accounts. For example, the idea of "root" means nothing in SELinux. A process with uid root can't get out of its confined security context and go rampant just because of its root privilege.
Regarding Windows' filesystem access control, it is similar to POSIX ACLs found in almost all Linux distros. These ACLs define the fine-tuned relationship between users and filesystem objects. However, filesystem access control is only a part (albeit important) of OS security, and I think neither SELinux nor Windows UAC is meant to work only in the realm of filesystem control.
Anyway the above description is based on my vague memory of these stuff and I could be wrong.
Colorless green Cthulhu waits dreaming furiously.
It's my business where I install the OS. It will only be on one computer at a time, but if I pay the money, the OS goes where I decide when it suits me to reinstall, without a penalty to ME.
I agree completely. I always get modded as a troll, but forced activation really is one of the things that keeps me from using Windows Vista. Every product that I've used that has activation has, at some point or another, made it needlessly difficult for me to do something legitimate. I just refuse to deal with that stuff anymore.
I have enough problems with software working properly without the developers embedding kill-switches in their software.
Unless you work for a vendor that sells Linux-based solutions, and have a job title something along the lines of "Deployment Options Specialist", there really isn't any reason to *try* to think about all of the various configuration and deployment options. What would be the point? You're Doing It Wrong.
The right approach is to ask, "In our situation, what do we need the software to do?"
Cut that out, or I will ship you to Norilsk in a box.
What is generally discussed (and ridiculed) on /. is what is termed UAC prompts
UAC prompts are merely the visible part of UAC. It's no surprise that the most important parts are hidden beneath the surface (and why it is so stupid to turn it off).
UAC introduces a concept called process integrity. One can consider it a subdivision of user accounts as it works by modifying the security token associated with the process.
If a process is running in "low integrity" it has virtually no rights to file system, registry database, IPC etc. It may render on the designated desktop and may also use an isolated storage. It is important to point out that because this sits in the security token, it is an intrinsic protection. IE7 and Chrome leverages low integrity mode, so even if an "exploitable" bug is found in IE7/Chrome or in an addin, this presents a formidable barrier to compromising the machine or even to get to sensitive or personal data.
Because a low integrity process is so limited, the browsers cannot even download files, except to their local, isolated storage. Therefore UAC calls for a separate broker process which drives the familar "save" dialog and reaches into the isolated storage and marshals the downloaded files out to userland.
Aside: When Vista was compromised at last years pwn2own it was through a custom broker process which Adobe had bundled with Flash. In their wisdom they had allowed the broker process to launch external programs. They needed at to perform updates or something. Go figure. Other integrity level are normal and elevated. In normal integrity level you cannot perform any actions which requires administrative privileges. In that case you need to elevate your privileges. That is where the UAC prompt comes in. To summarize, while UAC addresses some of the same concerns as SELinux, it does so by reigning in the process as opposed to SELinux/AppArmour which reigns in applications by defining profiles with allowable actions per app. I suppose you could build something like UAC by using SELinux and inspecting the process, but I'm not aware that this is what SELinux does.
One obvious difference - an advantage to UAC if you will - is apparent in the case of browsers. If a browser needs to be able to upload and download files, it must have a policy defined for that under SELinux. Hence, a compromised browser can also read/write files from/to those same locations without the users' knowledge or consent. That's not possible with UAC and IE7/Chrome. There is only one way (if UAC is not buggy) to have files transferred, and that's through the broker process. Assuming that process is not buggy (looking at you, Adobe) the user *will* know when a file is being downloaded and saved.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*