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();
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.
This space left intentionally blank.
I still don't understand why they don't just sandbox any application that wants to be installed and only when it tries to access user data there should be a prompt.
You know, something like "Market watch X wants to inspect your porn collection [allow] [yes]" instead of "blah blah privileges blah [allow] [maybe]"
Second, changing the level of the UAC will also prompt for confirmation.
Oh great!
a confirmation for the confirmation dialog...
Slashdot ya no es que lo era!
What? Windows' ACL much more complex than the "proper" user, group, and world method in unix. The NSA built SELinux to address this. In other words, Linux needs to catch up to windows.
The UAC wont ask for a password if you are already an admin. if you want to input a password you can run as non-admin, as you should be doing.
Couldn't they set it up with all the crazy user restrictions in place and then just add that nice little checkbox that says: "Do not alert me again."
Most of the computer users on the planet will think twice if the alert is made simple and clear.
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.
to change anything in the UAC I'll get a 'confirmation' box that I'm running something with Admin privs, I'll need to authenticate, requiring another dialog, then when I change the level I will get ANOTHER dialog asking me to confirm my changes?
Man, that's brilliant, let's add yet another dialog asking 'Are you sure you want to do this? Really, really sure?'
Wow. I have to admit, this level of bureaucracy makes the Federal Government look lean and mean by comparison.
Pax Vobiscum
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.
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.
Rich And Stupid is not so bad as Working For Rich And Stupid.
When _I_ read the headline, I thought it was an announcement of a new product called "Microsoft Caves", which would change security in Windows 7.
I figured that in order to improve security, they would put you in your own "cave" (figuratively or, perhaps, literally). Seemed like a terrible concept, but from the makers of "Bob", who knows...
"User switching now called 'visiting another person's cave'!"... uh... wait... maybe not.
--Coming up with something clever... please wait...
the uac model is inherently broken.
Citation needed. Along with suggestions on a better alternative.
This space for rent.
These Microsoft article responses are funny.
First it was tagged "whocares" which I thought was somewhat silly considering the related article ended up with 379 comments, many of which were condemning said UAC security hole. Obviously, a lot of people, even those who don't even use Windows, did care or at least found it interesting.
Of course thats all in the past since the tag seems to have been replaced by "astroturfing", which would be correct since the article was about a positive change. After all, we wouldn't want anyone to come under the false belief that anything positive from Microsoft is anything other than a PR scam to make you forget that they're evil.
Come to think of it, this article clearly needs the "itsatrap" tag!
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.
Pepsi. Pepsi pepsi pepsi. Pepsi, pepsi pepsi. Pepsi. *boom*
It's The Golden Rule: "He who has the gold makes the rules."
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.
Because at first MS declared it 'by design', and 'wont fix'. The 2 fixes they have implemented a great news, they claim at least one of them was planned anyway. I don't care how it happened, I'm just very glad it did.
Proper user account permissions? Like the ACL system that Windows has had for more than a decade? The one that's more granular than what you can get on Linux? I guess Linux needs to ditch sudo and get real "user account permissions" too?
I don't see what you're getting at here: UAC fills almost the same role as sudo on a Linux system. Okay, I admit - it's a little different "under the hood" from the way sudo works under Ubuntu, but it legitimately works, and Microsoft actually did sit down and think this one through. For example, instead of asking to elevate for every piece of software that does terrible crap like writing into the Program Files directory, it just virtualizes that file system operation into a folder in your user account. Doesn't even ask to elevate. It does kinda cause problems when files don't end up where you expected them to, but most users never notice and it's actually a very nice way to deal with developers who refuse to follow the rules. Thanks to nice things like that, I generally only get prompted for elevation when I install new software or legitimately need access to a restricted directory, which is exactly the way it should be.
Don't misunderstand me here - there's plenty of things wrong with Vista. UAC and the NT security model weren't one of them, though. UAC was a step towards a sane default of limited users instead of having everyone run as an administrator. Defaulting everyone to admin is one of those bad decisions Microsoft made and we've been paying for ever since. Windows needs UAC, and it's the main reason I use Vista on my home box.
Try this: enable Vista's Administrator account (it's disabled by default), give it a password, then make your user account a "Limited User." What happens when it asks to elevate? Yep, a password prompt instead of the regular UAC. It's not technically sudo but it's the same effect and it works extremely well.
"I do a grep for shit, bollocks, and tits before checking in code. I'm professional..." -RECURSIVE_META_JOKE, reddit.com
That's funny.. what does the registry have to do with the security in NTFS?
And explanation of how what Windows does is different from what KDE, Gnome or OSX do.
As I put it in another post (http://it.slashdot.org/comments.pl?sid=1118669&cid=26751749), SELinux is not just a user access control (UAC) system. The NSA didn't build it "to address this" as you said. Instead, they built it to implement a much wider range of ideas e.g. role-based access control and security context/type management.
I'm not familiar with the Windows Vista UAC so I can't make reasonable comparison between it and SELinux. However, if they are designed for different jobs, then we are really comparing apples and oranges.
Colorless green Cthulhu waits dreaming furiously.
Please check with the editor for current rates for astroturf articles.
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.
Sounds like Group Policy Objects in Windows (running in a Domain).
Home of Microsoft Trolls?
Read this post. NT's POSIX ACLs came from the same place that Linux's did; Unix.
proper user account permissions (a la UNIX)
You mean "me, us, anybody" permissions? Windows account security is both more sophisticated and more granular. The problem is not with user account permissions, but with the out-of-the-box defaults. On this one, Microsoft can't win. If they do something that's appropriate for the average home user (a breed of cat most of /. can't even imagine), power users and tech writers get all over their case.
In the enterprise environment, the degree of user lockdown is easily adjusted on a per-user basis and runas (Windows' sudo -u) is available for exceptions.
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
6 seconds, Pepsuber!
Here 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.
The super-shotgun? Or alternatively BFG? (Though you may need a red key for that one.)
If you don't know what AltaVista is (was), get off my lawn.
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.
It's been years, and I still chuckle when I see a reference to Microsoft's UAC. They couldn't have chosen a more appropriate name for it!
Cantankerous old coot since 1957.
Flamebait mod :(
The idea was to make a joke about how although Slashdot is pretty anti-Microsoft, there's a veritable advertising campaign here for their latest product iteration. Irony, you know? Clearly I bodged it though...
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*
Sounds like Group Policy Objects in Windows (running in a Domain).
If it sounds like it, I hope you haven't done much administrating Domains recently.
But maybe you're right, so... how can I create a GPO object that gives the following MAC profile to any instance of Firefox, started by any user:
- disallow connecting to ports other than 80 and 443
- disallow reading files in the User's home directory
- allow reading and writing files in %AppData%\Firefox, but not reading anything else in %AppData%
- allow writing files to %TEMP%, but allow reading only of the files created by Firefox itself
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.
More granular? You mean like Posix ACLs and NFS ACLs?
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.
Yup, SELinux is designed to allow government computers to process data of different classification levels, without causing all data to adopt the highest level.
For example, if you copy a confidential file onto an ordinary secret machine, that file then becomes secret. If SELinux is implemented, then a machine can be designed to process both confidential and secret data, without all confidential data becoming secret. However, setting something like this up and getting it certified by the NSA is a friggen huge PITA.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
There is another feature that auto-elevates that can and will be used.
When you use Explorer to drag and drop files into a directory you don't have write access to, Explorer will ask whether you'd like to use your Administrator permissions to complete the task. If you say yes, it will launch a program as Administrator that does the actual copy.
The problem is, this program in Windows 7 is one of the special ones that self-elevates without the UAC dialog box. Because Explorer doesn't run with Administrator privileges, and because the confirmation dialog box is within Explorer, a malicious program can use the file copy program to do any file operation with Administrator privileges, and it will happen without any user input in the default installation.
Surely that will be abused...
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
But to continue on from that question, you need to find out which of the particular options available to you can do what you need it to. That does require knowledge, to an extent, of the options.
ZDNet's flash player sucks and didn't load so I found the actual flv.
http://media.cnetnetworks.com.au/video/2009/02/22470997/22470997.flv
OP said:
You're aware the access controls of the Windows NT line is MORE fine grained than UNIX, right?
indicating that more fine grained controls via ACLs etc is better than the ugo model that standard unix uses.
I'm merely pointing out that this is a beyond stupid argument, since Microsoft often claims that the registry is far better than /etc config files, and we all know how fucked up the registry can be. Here's an article on why Microsoft thinks the registry is better than /etc config files: http://www.theregister.co.uk/2002/11/21/ms_paper_touts_unix/
And for the morons who keep harping on SELinux, you either have not implemented this in production, so, stfu, or you're paid too much to screw around on slashdot, so go troll somewhere else. For the rest of us, selinux is a damned pain in the ass, and no sane person touches it.
Could you explain how Group Policy in Active Directory is at all similar? For the most part, Group Policy is a way to push registry, system, and application settings out to members of the domain. While it is forced on user accounts, applications can ignore the settings if they so choose, meaning it is nothing like SELinux.
Said, "It's just like dice but it's got more sides And it tells me who lives and who dies"
They are both bloated and broken paradigms that are often used inappropriately? Or maybe it was just a misplaced attempt at sarcasm from "the B0fh".
Said, "It's just like dice but it's got more sides And it tells me who lives and who dies"
Most Linux distributions I've used, including Fedora and Ubuntu, prompt me for my password whenever I try to go into some system menu or app, like the networking configuration. That's very similar to UAC popping up and asking for permission. My other option in *nix is to log in as root to make all those changes, but that requires knowledge and taking the time to switch users. Either one of these options is arguably just as intrusive as UAC, so I really don't know what all you people are talking about.
Beware of bugs in the above code; I have only proved it correct, not tried it.
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.
First, there are specific SELinux user contexts that refer to root (as opposed to a regular user), so, yeah, SELinux does have the idea of "root".
Second, you have to be able to administer the system somehow, and SELinux is part of the system. And, you really don't want SELinux being the part that restricts what can configure SELinux, because then one screwup and the system is hosed.
For a truly secure system, it might not be the case, but with every SELinux-enabled distribution I have seen, "setenforce 0" as root will let you do anything you want.
It's good they've responded, but this change does not fix the fundamental problems with win7's UAC whitelist.
The problem is that 70 applications are on the whitelist and are allowed to silently elevate without the user's knowledge. You just have to inject code into one of these 70 applications and you have admin rights. There are multiple ways of doing this. You can use the debug API, you can get them to load a DLL, use your imagination.
Here's a page with a sample exploit and a lot more information:
http://www.pretentiousname.com/misc/win7_uac_whitelist2.html
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.
No, that's not what UAC does at all. UAC has nothing to do what that applications can access, it has everything to do with USERS can access. It's exactly the same as trying to do something in Gnome that requires administrator access when you're only a normal user and prompting you. The difference is that if you're a normal user in Windows, you need an admin username / password. If you're user account is already a member of Adminstrators, you just need to click a confirmation dialog. But it's the same concept and doesn't doing anything based on what the application is or wants to do.
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.
They may have the same goal, but UAC is completely different in that it works within the existing security token and ACL framework.
UAC can't do things like stopping "cmd.exe" from writing to a file in C:\, while SELinux can do the equivalent. In Windows, the process runs with the security token of the user, and that completely controls what the process can do.
UAC just alters the security token so that processes aren't always as powerful as the user really is. Although you could implement some form of the same control that SELinux offers by having users like "cmd.exe" and assigning "deny" permissions to that user for objects it should not access, this would add a lot of bloat in the filesystem security descriptors. It would also be very difficult to set up the correct permissions so that all this worked across a network, and wasn't avoided by merely renaming the executable.
It's simple, really. The concept of UAC is broken, not the implementa... ok, they're both broken, but you can only fix one of them.
The idea that the user can even make these decisions is fundamentally flawed and shows that MS is run by either geeks (who don't understand that human life is possibly with knowledge of stacks, heaps and pointers) or lawyers (who don't care about users at all and only want to see responsibility shifted to parties outside the company as much as possible).
90% of windos users can not decide security questions. You could probably put "process X wants to wipe your harddisk and anally rape your kids, Allow or Deny?" up and they'd click "Allow". Part by habbit, part by stupidity, and part because they've been asked questions they can not possibly know the answer to for years now and learnt that unless they click "Allow", they can't continue doing what they want to do.
Assorted stuff I do sometimes: Lemuria.org
I completely agree. This ad campaign is getting seriously annoying. Not a day goes by without a story about Windows 7, an operating systems months from even RC, and which from what I understand, is essentially to Windows Vista what Windows 98 was to Windows 95.
Do we really need 5 articles speculating about how many versions Windows 7 will be released in?
Do we really need separate articles about every little supposed improvement over Vista?
Bullshit. Try using your POSIX ACL's on NFS. Good luck with that.
Comment removed based on user account deletion
No. Nobody but single-OS shops use NFS ACLs. And POSIX ACL's are pointless as they only work on the local FS.
How I love it when good info is mixed well with bullshit. :-)
SELinux and NT permissions are not the same thing. SELinux isn't about ACLs, it's about MAC and RBAC and (incompletely when it was released) also about MLS. If you don't know what any of that means, you shouldn't be talking about how it is "like NT".
Assorted stuff I do sometimes: Lemuria.org
4-5? Is the maths really that hard?
Windows Vista introduced Mandatory Integrity Control which is a form of Mandatory Access Control.
Now if we could only replace UAC with DRM
The Kruger Dunning explains most post on
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.
I believe in SELinux you can do something similar via "domain transition". If the rule is set properly a browser can have no read/write rights to the files. When it absolutely needs to do so, it must be done by a "helper" process whose security type is transited into the corresponding type capable of doing the requested operations. There are many ways I can think of to do this. Examples would be the browser sending a request to a local authorization daemon, and let it take care of the rest. The daemon then asks the user for authorization. It continues to process the request and run the "helper" in the transited context only when password and confirmation from the user are given. Well this doesn't sound like an optimal solution (the authorizer daemon becomes a single point of failure just like the Adobe one) but that's quite close to what the Windows UAC can do in a similar scenario. By this made-up example I'm merely stating the possibility of implementing this through SELinux mechanism.
And I may be wrong.. I'm no expert in this area. I just happen to be interested enough to get myself into it a bit.
Colorless green Cthulhu waits dreaming furiously.
It redirects to 'silent' directories, won't allow a user to delete a directory they create, becomes a nag.
Bases your security on application behavior, implement proper sandboxing, stop using shared dll's.
Just as a start.
The Kruger Dunning explains most post on
Sure, the prompts are, but it also ... messes around with various directories that MS have decided are sacred, silently redirecting write operations to other places.
And on your Linux box, can you write to /usr or /etc as an unprivileged user? It's a security trainwreck if you permit unprivileged users to write to program files. Windows is saddled with the legacy of allowing this, all the way back from its single-user non-networked heritage.
In Vista, MS did the right thing and made Program Files non-writable except as admin. To make sure legacy programs still worked, however, they had to allow programs to think that they were writing to the shared files, without actually affecting other users. The only logical way to do this is to allow the change to go through, but only let the user who made the change see it.
It's also worth noting that this is likely to be a transient issue. New programs should be writing per-user customizations (e.g., runtime configuration) into the user's home directory, as Unix has always done. But old programs still have to be supported somehow.
What would you propose that MS do instead of this rewriting? Let all users write to programs in system directories that other users run, or break huge numbers of legacy programs?
MediaWiki developer, Total War Center sysadmin
- disallow connecting to ports other than 80 and 443
Proxy server
- disallow reading files in the User's home directory
ACL
- allow reading and writing files in %AppData%\Firefox, but not reading anything else in %AppData%
ACL
- allow writing files to %TEMP%, but allow reading only of the files created by Firefox itself
Hmm, the only way I could do that is have Firefox running under alternate credentials of a user setup just to run Firefox.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Removing DRM from Vista would only result in users being unable to playback DVDs, BlueRay, and other DRMed media.
If you are unhappy with DRM (who isn't?) go bug your government, senator etc.
You are not still buying into that Peter Gutmanns BS are you? If so then I have some stocks left for a very popular tower in central Paris. I will let you have them really cheap, their high profile considered.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I didn't believe this was a marketing ploy. But, I have noticed that "news" about Windows 7 seems to hit the press almost every week, almost like clockwork. I myself have wondered whether there is a new marketing regime in Redmond who knows how to play the "open" game.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
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.
No, the closest thing in windows is the Mandatory Access Controls used in services.
Services are given specific abilities to read/write only specific things, and nothing else.
Of course, you could always do this with windows just by making each service run as a separate user, and give that user specific access controls. It's just a bit easier with the new system. And no easy way to do it with desktop apps.
There's also integrity levels, which prevents communications (rpc, window messaging, etc) from a lower integrity process to a higher integrity process.
indicating that more fine grained controls via ACLs etc is better than the ugo model that standard unix uses.
They are. Provably and demonstrably so. ACLs are a superset of the UNIX security model.
Look, I agree. After I posted, I had looked up SELinux (I have no experience with it) and it's very different. Granted in a Windows environment I could achieve a similar effect to what you wanted - but it wouldn't be all Windows' utilities. It would require scripting for most of the work (if not all). As I look more into SELinux I'm very impressed with the application restrictions/allowances and the granularity in which you can control 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.
You mean like sudo isn't needed in UNIX ?
Sounds like Group Policy Objects in Windows (running in a Domain).
No. It's not even vaguely the same.
SELinux is an implementation of Mandatory Access Controls.
Group Policy is a form of centralised configuration management (a decent implementation of which is something sorely lacking in the OSS world, but that's another discussion).
First you wanted a more secure Windows and then you didn't like the way it was done, then wanted it removed or changed again. Kudos to you.
Why are you conflating utterly unrelated things?
The argument is that windows ACL system is superior because its more fine-grained than UGO type security on unix systems.
Your response is that its not true because you dont like the registry???
Talk about fail-whale.
Sure, the prompts are, but it also restricts what can be run at startup (regardless of permissions)
No, it doesnt.
You have 20-30 services (maybe more or less) that run quite well on startup and dont have anything to do with UAC.
messes around with various directories that MS have decided are sacred, silently redirecting write operations to other places.
No, it doesnt.
That is program file virtualization, not UAC. And its not on by default.
Exactly. And to be in the position where the "Deployment Options Specialist" has nothing but boilerplate means someone has already gone through the dizzying set of options and configuration possibilities. Many without a moniker such as, "Deployment Options Specialist", are often left with a large set of possibilities to choose from.
Since my original post was moded troll, to be absolutely clear, I was not being snide with that statement either. For many, having a very large set of options is simply too many options, creating confusion. It has frequently been a complaint levelled against Linux. Some consider it an advantage - others a disadvantage.
However true, you said something anti-linux. With such a low uid, you really should expect to be modded down by now... ;)
And you're not supposed to be running as root, EVER, and in a proper installation, only God has that authorization.
Simply put, I highly doubt the NSA gives anyone root access to their machines.
Of course, you can buy expensive software packages that claim to do this for Windows. Look at what the bug AV vendors sell for non-signature AV (for appliances and such). But those packages don't really work - because you need this protection built into the OS, not added on. The packages hijack the Win32 APIs - all well and good, but programs don't *have* to use the Win32 APIs to make system calls, so if you can e.g. launch a 16-bit app, or a Posix app, all bets are off.
The SE Linux thing is impressive because of the dilligance applied against such work-arounds. Dissociating permissions from users really is the way to go for this kind of security (and dead-simple unix permissions are enough for user-based file access control in practice, once you're only using them in a simnple way).
Socialism: a lie told by totalitarians and believed by fools.
At some point, some program has to run as root, or else many things (like starting services, updating software, etc.) can't get done.
It's active on my Vista install, and as far as I can remember I never chose to turn it on.
2 mistakes:
1) the prompt does not elevate to administrator, it elevates from "low integrity" to "normal integrity". UAC has more levels than sudo, you know.
2) The prompt comes from the Internet Explorer broker process. It is not under control of IE. IE can request (send a message) to the broker process requesting it to "marshal out". The broker process is not under control of the low integrity IE process running the rendering.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Obviously you're unable to relate two separate concepts together.
I'm showing an example where you have shitloads of finegrained stuff, and how it is a failure.
The OP's point here is that a fine grained ACL system (that was copied from VMS) is superior to UGO on unix. My point is that it is not. And I used an example from another part of the system showing that it is a pain to do it properly.
And actually, I took it a lot further than it should have been - ACLs are useful too. But really, implementing on UGO or ACL requires a lot of planning and thought up front.
Will you allow this change?
ALLOW CANCEL
Allow
Huh? I said something anti-Windows and marginal at that. It was a fairly pro-Linux posting.