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."
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.
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.
Yes, that is exactly what happened. Microsoft's previous comments on the matter basically boiled down to "What problem? This works exactly the way we intended it to."
I've been running Vista on my home/gaming rig for over a year now. It runs Steam, Fallout, Oblivion, Half-Life, Office, DevStudio, Firefox, Thunderbird, KeePass, Paint Shop Pro, Python, AV, iTunes - lots of stuff, some old, some new, some MS, lots of ISV.
I probably encounter a UAC prompt every week or two. Going into the control panel is pretty much guaranteed to trigger it, ad does updating a device driver, or installing/updating software.
That's pretty much it. I have at least one app that writes settings into its program files directory, but Vista silently redirects that to somewhere in the profile directory without requiring UAC.
The reality is that MS has been pushing ISVs for years to stop relying on admin access. Look at the requirements for getting the Windows logo on your app - one of the reqs is that it has to run as a normal user.
Between that pressure and the fact that Vista does trap and redirect some of the most common accesses to HKLM and Program Files, most shrinkwrap userland apps work fine in Vista.
When you start talking about things that a guy in the IT group whipped up in a few days back in 1998 thinks aren't nearly as rosy, but most home systems don't have to deal with that crap.
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*