Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security Operating Systems Software Windows

Microsoft Caves, Will Change UAC In Windows 7 249

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."
This discussion has been archived. No new comments can be posted.

Microsoft Caves, Will Change UAC In Windows 7

Comments Filter:
  • by Anonymous Coward on Friday February 06, 2009 @10:24AM (#26751223)
    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.
  • by javacowboy ( 222023 ) on Friday February 06, 2009 @10:35AM (#26751361)

    First of all, Microsoft screwed up initially because DOS and the non-NT versions of Windows didn't implement the concept of a multi-user, networked operating system like Unix and NT did. This means that when the internet took off, Microsoft was selling an operating system for the masses that was not architected to be used securely over the internet.

    The consequences were disastrous. Malware, including viruses, warms, trojans, adware and spyware spread like wildfire over Windows systems over the internet. Zombie machines became common. Software was written to require admin privileges to install and run correctly.

    By the time Microsoft realized they needed to fix the problem (between XP and XP SP2, depending on how you look at it), there were too many legacy dependencies for Microsoft to switch whole-hog to a Unix style multi-user, restricted user by default system.

    Still, they did try to do something about it. They merged NT and 9.x into a single operating system and kernel, namely, Windows XP. It was now possible to create multiple users, including admin and non-admin users. They implement the Run As functionality, to allow non-admin users to temporarily escalate their permissions.

    I know Run As mostly worked, because I spent a few hours setting up my dad's XP and Vista computers with regular user accounts. There's the odd program that doesn't run correctly (or at all) as a regular user, but they all run correctly with Run As. I think there was only one program he had that used to run correctly under his old account that didn't work at all under the new setup.

    Still, there are third party software developers that perpetuate use of the old system, and force Microsoft to enable admin users by default. Among those are game developers, that require users to run as admin *AND* stay connected to the internet (I believe Half-Life 2 requires this, but I'm not sure). This is grossly irresponsible, and Microsoft needs to do more to discourage this practise.

    Still, as awkward as it initially was, UAC was a step in the right direction. It was too obtrusive in Vista, so they toned it down in Windows 7. Now, they realize they need to go partway back in the opposite direction again.

    I'll give Microsoft credit for trying really hard to fix their past mistakes. However, some third party developers need to be smacked down hard for forcing Microsoft to maintain its past mistakes.

  • Re:Caves? (Score:3, Informative)

    by DavidR1991 ( 1047748 ) on Friday February 06, 2009 @10:44AM (#26751465) Homepage

    "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?"

    They stated it was by design a few days ago, immediately after the issue was posted, that's why

  • by Dystopian Rebel ( 714995 ) * on Friday February 06, 2009 @10:47AM (#26751511) Journal

    I agree about the flawed permissions architecture.

    I use Ubuntu ("Canonical's Debian") and OS X. But not everything runs in WINE so I do have an occasional need to run MS for contract work. I have no more patience for WinXP's constant updates (many requiring a reboot) and it's growing harder to find Win2K drivers, so I tried Vista. It is availble for 64-bit (more addressable RAM) and it has outbound firewall blocking (that's good). Vista looks better than previous versions and the UAC is truly NOT so annoying as has been portrayed by Apple's advertising. I see the super-user password dialog in Ubuntu and OS X just as often.

    I *have* run into problems with the Program Files folder in Vista. Some applications need to write in there and sometimes *I* want to write in there, but "for safety", Vista won't let me do it even if I accept the UAC dialog. It's inconsistent behaviour verging on buggy.

    I would consider Vista a worthwhile upgrade. But the biggest problem with Vista -- the deal-breaker -- is the licensing model. 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 want a long-term investment in my favour. It looks as though Win7 licensing will be the same as for Vista.

  • by recoiledsnake ( 879048 ) on Friday February 06, 2009 @10:53AM (#26751621)

    the uac model is inherently broken.

    Citation needed. Along with suggestions on a better alternative.

  • by Anonymous Coward on Friday February 06, 2009 @10:55AM (#26751647)

    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.

  • by gzipped_tar ( 1151931 ) on Friday February 06, 2009 @11:01AM (#26751749) Journal

    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.

  • Re:Caves? (Score:5, Informative)

    by BRSQUIRRL ( 69271 ) on Friday February 06, 2009 @11:05AM (#26751833)
    Yes, that is exactly what happened [winsupersite.com]. Microsoft's previous comments on the matter basically boiled down to "What problem? This works exactly the way we intended it to."
  • by clodney ( 778910 ) on Friday February 06, 2009 @11:12AM (#26751975)

    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.

  • by Cowmonaut ( 989226 ) on Friday February 06, 2009 @11:36AM (#26752419)

    Here [wikipedia.org] is some info on SELinux. Some people apparently don't Google things they don't know about before posting (still, its only been a few years) and others like to not explain things so they appear to know what they are talking about.

    The patches for SELinux have the same goal as UAC (and vice versa). That is, they provide a means of controlling what various applications can actually access on a PC. With UAC, MS makes it pretty intrusive and seems to punish the user but overall it is a good thing. If they can make it not so annoying it'll go a long way in making Windows more secure (for about a week).

    By the way, the patches for SELinux are built in to the 2.6 kernel now so every Linux distro can or does do this.

    Anyways, all they've done here is make it harder for UAC to be disabled without the user being aware. This is important since they've changed the default behavior of UAC so you won't see it as much since they found people only hate UAC when they see more than 2 prompts in a session.

    I imagine in a week and a half someone will have figured out how to still disable UAC without the user being aware or just take the shortcut already suggested and have the programs piggy back on ones that already have admin rights.

    It must suck being a large target that didn't start out secure. Securing Windows must be a right pain.

  • Re:Intense? (Score:3, Informative)

    by thethibs ( 882667 ) on Friday February 06, 2009 @11:48AM (#26752673) Homepage
    Dilbert?! Is that you?
  • by benjymouse ( 756774 ) on Friday February 06, 2009 @12:14PM (#26753217)

    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.

  • by EXTomar ( 78739 ) on Friday February 06, 2009 @12:18PM (#26753311)

    SELinux provides a consistent mechanism for runtime policy rules in terms of a execution context. That isn't to "provide the same granularity of Windows" so if you want that you need to look elsewhere.

    The reason why SELinux is important is that it goes to the next step of control. For instance, assuming a system is configured correctly to access the Firefox binaries and necessary files, a problem still arises: The Firefox process, once launched, has access to everything the user that launched it has access too. There is no earthly reason why Firefox would load "libsmb.so" or any number of things in "common directories" by nefarious people may try. A way to protect that is start refining the system to "contexts" where it is recognize many processes shouldn't have such broad access. Under SELinux, one can create a policy for Samba enforcing only Samba tools can load Samba shared objects. Now it doesn't matter what user is running Firefox (even the all mighty "root"), the system won't allow Firefox to dynamically load "libsmb.so".

    The trick is that creation of these polices takes time and a lot of tweaking and hard to keep generic. SELinux is very much a work in progress but I'm glad it is work being done. And importantly, this isn't done on Windows yet either. The analogous mechanism on Windows is an AV Scanner which isn't desirable due to be inconsistent (one AV vendor may handle Firefox loading "smb.dll" differently than another) and not as desirable since it is "watching and catching abuse" instead of preventing it by design.

  • by Nursie ( 632944 ) on Friday February 06, 2009 @12:27PM (#26753477)

    UAC is nothing like sudo.

    Sure, the prompts are, but it also restricts what can be run at startup (regardless of permissions) and messes around with various directories that MS have decided are sacred, silently redirecting write operations to other places.

    It's annoying and broken.

  • by benjymouse ( 756774 ) on Friday February 06, 2009 @03:22PM (#26756351)
    UAC will only redirect read/write operations for files and registry for virtualized processes. Apps compiled with a proper manifest are assumed to be well-behaved. Only older apps without a proper manifest is assumed to be "broken" and to keep them running the write operations will be redirected per user. It is by no means a perfect solution, but it does allow some apps to run which would otherwise have failed badly.

Intel CPUs are not defective, they just act that way. -- Henry Spencer

Working...