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.
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.
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*