Submitted by One of Vista’s big security features is ‘User Account Protection’ (or ‘User Account Control’) which pops up and asks for user authentication before software can make any administrative changes to the system. But the TweakVista utility can turn off UAP in one click. Microsoft says this is UAP working as intended, because when a user runs TweakVista they are asked to authenticate. However, James Bannan at APC Magazine asked Microsoft what’s to stop a downloaded ‘freeware game’ requiring user authentication upon installation and then disabling UAP altogether? Elsewhere, there’s a tweaking guide for Vista RC1.
Am I the only one that finds windows/*nix security completely stupid? I mean, think about it, the only time a program should ever need to modify user/system files is when the user explicitly tells it to, e.g. by opening said file in the application. The fact that my OS allows any random app to modify any one of my files is possibly the worst idea I’ve ever seen, and the only reason I can see for doing this is sheer laziness.
What about when you run a configuration application? Like a preferences tool? What about when an application needs to set up file associations? Install shared plugins? There is any of a number of reasons an app might need to modify system files.
Application files aren’t system files, at least not the kind I’m talking about. Ever heard of an application directory?
Application files aren’t system files, but things like media plugin directories and the file association tables usually are.
Ok, so what you’re talking about can be system files in a poorly designed system; what’s your point? File associations can be easily derived by the OS assuming the information is available in the app dirs and plugins belong with the application.
So where do you store global changes in file assocations? Say I want to set up a machine so that Firefox is the default browser for all users (because of company policy). How does that preferences app work?
How does that preferences app work?
It doesn’t let you do anything that isn’t governed by policy regardless wether you are root or not.You could easily make a working policy for roaming profiles.
What’s to easily deactivated can’t really benefit security in my opinion.
Since when is firefox associated with any files? If you want to make firefox the only browser, just stick it in the global ‘applications’ directory and remove anything else.
The point is that just scanning application directories for file associations doesn’t work, because there is no way to remember defaults. Let me give you a real concrete example. On my system, I have two apps that can handle torrent files: Transmission, and Democracy. The two apps are different — one is a BT downloader, the other is a web interface to TV shows distributed via BT. I want Transmission to be my default handler for when I open a torrent file, but I don’t want to be able to use Democracy as a standalone app. Moreover, I want these settings to be system-wide.
How do I do that under your scenario? Having the OS scan the application directory doesn’t work, because it’ll find both Democracy and Transmission, so how does it decide the default? It could pick the first one it finds, in this case Democracy, but that’s just user abuse. Ensuring that there is only one file handler for each MIME type doesn’t work, because on a usual system, there are multiple apps that can handle a given MIME type. It needs a file to store the user’s preference. This file can’t be user-local, because the desired scenario here is a system-wide setting. Hence, the file association table must be a system file. Since its a system file, you need some way to grant a preferences app the permission to modify it, which brings you back to some sort of password-prompt as in UAP.
The Firefox example is identical to the one above, just replace Transmission with Firefox, torrent files with HTML files, and Democracy with IE.
Edited 2006-09-09 23:43
I want Transmission to be my default handler for when I open a torrent file, but I don’t want to be able to use Democracy as a standalone app.
Wait, what? Why do you have it installed if you don’t want to use it?
localy saved htm and hmtl files.
and i belive that windows define urls as a special kind of file
Yup, that occured to me a little bit later
i guess that why you have a home os and a office os.
both can run the same apps, but the home os have diffrent security defaults and design as you will not have a central admin setting up policy and so on…
All preferences should be stored in the users home directory and NOWHERE else.
There are lots of settings that shouldn’t be stored in the user’s home directory. You usually want things like network settings, global file shares, printers, etc, to be non-user-specific.
That’s not a particularly good idea, either. A home directory is for user files. Besides, that doesn’t work well when you want two different version of an application to be stand-alone.
A lot of the per-user settings are stored in the HKEY_CURRENT_USER hive, which is in the user’s home directory (as ntuser.dat).
Install shared plugins? There is any of a number of reasons an app might need to modify system files.
You can never trust any application.What if a rogue program exploits a vulnerability in UAP since almost any piece of software has holes.It’s way better to have an extra (MAC) barrier a la SELinux AppArmor instead of the common DAC (file permissions).
There is any of a number of reasons an app might need to modify system files.
Some files just don’t have to be accessed or in very rare circumstances.An installer normally doesn’t need to add users exept with special permissions.
The prime is you don’t grant users permissions but software.In this case admin privileges.Which is something to not take with a grain of salt in my humble opinion.
This is such a stupid idea that it boggles the mind. Instead of designing an interface to UAP that doesn’t suck, they’re just going to include a kill switch instead. What this means is that any hope of increased security in Vista just went out the window. People, pesterred by the constant annoyance of the UAP interface, will now just get their resident geek to turn it off for them. At the same time, it removes any impetus among the UAP developers to actually improve the interface! Stupid, stupid, stupid.
Oh yes, designing a better box that asks for your password…. that is going to help everything…..
It boggles my mind is that so far there are only a few posts on this article, but 100% of them didn’t even THINK before they posted.
There is an option to turn off UAC… big deal. If there was no option to turn it off it would be MUUUUUUCH worse.
TweakVista is just takeing advantage of the option that is already there. You can’t have the option to turn it off and somehow lock out any other application from being able to do the same (Especially one with superuser privelages).
UAP is only truely annoying when you are first setting up a computer (as your installing all your apps, most of which were designed with admin rights in mind, and not propper multi-user design).
Once develops start to actually think about what they are developing and how you don’t need to force admin privelages to run their stupid app, then UAP will become even less visable.
The box that asks your password is completely retarded in its wording, so yes, fixing it would be a step up.
One of the major problems everyone complains about is the frequency of password requests in Vista. Better interface design would go a long way in fixing this.
And no, a feature like this should *not* be overridable. Users should not have the option to compromise their own security. That was one thing before the advent of the internet, where messing up your own machine only hurt yourself, but in this day and age of networked computing, turning off security protections is like disabling the fire alarm in your apartment. You’re not just going to hurt yourself!
The Security Center bugs you non-stop as soon as you do.
question is, how can the os tell that a user told the app to modify a file?
When the user inputs his password. Duh.
so every time i want to save a spreadsheet, a picture or any other file i get a password dialog? like the UAP wasnt anoying enough as it was…
so every time i want to save a spreadsheet, a picture or any other file i get a password dialog? like the UAP wasnt anoying enough as it was…
On the contrary.As the situation is now every process and or program has root access on a average home edition.The vendor should develop a working default policy.You can have a permissive (equivalent to having no MAC),a strict (everything denied by default unless governed by policy) and a targeted (everything allowed by default unless specified otherwise) policy.
An enforced targeted policy is a nice point to start with.You could restrict programs and or services known for their vulnerabilities to do only what’s intended normal and no more.For example ie6/ie7 would be a nice candidate to be governed by an enforced targeted policy.
This way even if there’s a vulnerability the policy denies everything that’s not normal usage,wether run as admin or not.This way the vendor doesn’t have to rush things and can thoroughly investigate the obstacle and release either a new policy and or a patch.Aka SELinux,AppArmor..
Your spreadsheats aren’t affected.
Edited 2006-09-10 07:38
and what happens the moment a new attack is found using a app that was considerd safe before? does the corp (microsoft) roll out a new policy using their update software?
rember that one of the now “old” ways of spreading a virus was by mailing people a ms office file, be it a spreadsheet or a text document. this worked because ms office had a buildt in scripting function.
only the most simple of apps that do one job can be said to be safe. ones you start stacking on jobs and features you increase the risk that there is something someone can exploit.
then there is the human factor. ones a person gets used to seeing 1001 password dialogs, he will start to type it in automaticaly when something looks like a password dialog. force of habbit and all that…
basicly this is the same problem that one have with DRM. as long as the admin (as in the person that configure and installs software, not the account) is allso the user, security goes down the drain.
oh and btw, all this comes from the first post i replyed to. the one bytecoder wrote about the os only allowing apps to modify files when the user explisitly said so.
Edited 2006-09-10 07:55
To be honest, this does seem a bit silly on Microsoft over this. I mean, on any system with this sort of security model (OS X, Unix & Linux etc.) all one program has to do is claim it needs the root password, and then bingo, it can do what the hell it likes to the system.
So, you want to get rid of root altogether?
Did you even think about what you posted before you posted it?
Why not? I mean you could have a different system usergroup account for each critical group of related files (with the obvious default of one unique user per group). So you could a have a usermanager user who is the only one able to read and write to those files dealing with users groups are their permissions. Another one for controlling hardware configuration and drivers and partition loading. Another one for controlling which applications get installed, nad yet another for automatically patching everything. Now you could simulate a root user by merging having a single account “inherit” from all those groups: that should be discouraged. This was if you break into an account they can only bork those things. Now this still leaves the permissions account as a vulnerability but then that oneshouldn’t be needed very often anyway. With a single account to really worry about and one that shouldn’t need frequent access it would be easier to secure (for example making the user enter 10 catchas correctly is not that arduous if you only have to change permissions at most once a day and frequently less than once a week). If you think this is far fetched check the owner of the folders for your database or webserver: most of them alredy have dedicated accounts.
Maybe my suggestion is not the best one, but my point is that it is doable. The specifics would obviously need some work.
Ummmm I’m pretty sure that if you asked even the most hardcore admin to remember 15+ passwords for your “fine-grained” root system, that would lead to both insantiy and an outbreak of passwords on sticky notes.
and thats one introduce keycard keychains
or multikey cards
Most mainframe/miniframe OSes like VMS or OS2200 use a permissions bitmask instead of the all-or-nothing “root” concept, with some permissions limited to only certain USERIDs at hardcoded locations (say a system console behind multiple layers of locked doors).
There are several dozen calls to the OS which are privileged in nature and require the appropriate bit in a user’s permissions mask to be set, and users can have 1, 2, a bunch, or none of these as required.
This idea allows a process to run under a user account which has only been granted the permissions which are absolutely required and no more. A buffer overflow would get you access to the set of permissions granted to that user at run time, but nothing at all outside of that set.
Also, because some parts of OS security are enforced in hardware, certain types of extremely sensitive privileges can’t be transferred to a general user account at all — they MUST be performed from the predefined console accounts, or they simply can’t be done. Period.
I don’t remember how OS2200 does this, but I seem to remember that VMS has startup, normal, and current permissions masks for each user, not just a simple general mask, meaning one can have special permissions flagged at account startup time which can be used for setup purposes and then taken away before interactive control is passed to the user.
This type of thing has been done for 30+ years on other platforms. I’m not quite sure what is taking desktop OSes so long. The idea itself isn’t all that difficult, and putting all privileged eggs in one basket is a STUPID design.
Edited 2006-09-11 03:21
No, I am not suggesting removing root. I am just pointing out that this flaw is inherent to all of these OS’s and that it seems rather silly to pick on Microsoft for their implementation.
At present, I would criticise them for how often you currently are required to enter your password in Vista, but that is a completely different matter.
My point stands that the aforementioned OS’s are all vulnerable to effectively the same thing and that it all comes down to trust with the root/admin password.
“I mean, on any system with this sort of security model (OS X, Unix & Linux etc.) all one program has to do is claim it needs the root password, and then bingo, it can do what the hell it likes to the system.”
The difference holds in the program being open source (trustable) or not.
To me it’s pretty simple: disabling UAP should trigger a SPECIAL authentication process. e.g. it shouldn’t just be part of having elevated privileges overall — once a program has been authenticated for administrative privileges, it shouldn’t automatically be able to disable UAP.
If ANY program tries to disable UAP, Windows should pop up an alert warning the user that something is trying to disable a critical part of Windows’ security.
Frankly it’s arguable that the security layer is worth nothing if a user can disable it so easily.
Windows’ lack of ‘front of house’ security has been its fundamental weakness from the beginning. If you make it so easy for users to disable the prompts, people are obviously going to do it… because they’re annoying. Then viruses are just going to propegate as they always have before.
I must say Mac OS X seems to have the user authentication process right. There is no way of disabling it, but it doesn’t have as many alerts as Windows does, so it doesn’t get annoying. You really only need to authenticate when changing really important system settings, or installing software. Plus it doesn’t go the whole “greyed out screen” thing (that’s one of the things I find the most annoying). It just pops up a dialogue.
To me it’s pretty simple: disabling UAP should trigger a SPECIAL authentication process. e.g. it shouldn’t just be part of having elevated privileges overall — once a program has been authenticated for administrative privileges, it shouldn’t automatically be able to disable UAP.
If ANY program tries to disable UAP, Windows should pop up an alert warning the user that something is trying to disable a critical part of Windows’ security.
That’s not a bad idea. Even on standard XP, Zone Alarm as an example will pop up a dialog box asking for verification if an attempt to terminate the service is made by an authorized user or process. Zone Alarm prevents input redirection for itself, so any input has to come from the keyboard and mouse to prevent remote control or system scripts from “faking” input. The user has to specifically approve it. It’s a smart extra step to prevent trojans or backdoor applications from disabling ZA without the user realizing, even if they’re running as admin.
There’s no reason UAP couldn’t do something similar, along the lines of an “Are you really sure?” dialog box popping up. It’s hardly infalible but at least it could help protect those users that insist on clicking banners to download and install free smilies for MSN from totally hosing their system, unless they’re intent on it.
“If ANY program tries to disable UAP, Windows should pop up an alert warning the user that something is trying to disable a critical part of Windows’ security. ”
Ever hear of the “dancing pig problem?” If the average user sees something like this:
Click YES to see dancing pigs!!!
WARNING: This will destroy your computer, max
out your credit cards and ruin your
love life.
They’ll click away without reading the message and 30 seconds later they won’t even remember it.
To me it’s pretty simple: disabling UAP should trigger a SPECIAL authentication process. e.g. it shouldn’t just be part of having elevated privileges overall — once a program has been authenticated for administrative privileges, it shouldn’t automatically be able to disable UAP.
It possibly does. UAC is one of the items monitored in the Security Center. I haven’t tried disabling it, but based on the common behavior, you’d likely get the red shield and a notification. Fully disabling UAC
is supposed to require a reboot, however the APC article made no mention of them actually doing so. It appears they just saw the checkbox and assumed it could disable UAC in that same session. So either it doesn’t require a reboot, or APC didn’t fully disable it. Can someone test and confirm the actual behavior? I’m not in a position to risk a restart at the moment.
First off, I’m glad Microsoft is finally starting to think about security. I wish they’d done it in 1995, but better late than never.
The major problems I see are:
1) No application should be able to silently disable a security feature. Period, paragraph. I want a warning to come up, and prompt me to click “Yes, I know” or “WTF, Mate?”. Annoying? Yes. But anything else is a security hole waiting to be exploited. So, UAC needs two categories… One for “normal” usage (changing display prefs, running programs, etc), and a second level for security related changes (virusscan, firewall, UAC itself).
2) The “virtual writes” is great– But what if I want to install an application outside of Program Files? So far, it looks like I’m back to the WinXP model of “all or nothing” for those.
3) So far, the general advice I’m seeing for problematic programs under Vista is: “Disable UAC, run as Administrator”. Which means we’re right back to WinXP class security, which isn’t that much different from Win95 security.
and a second level for security related changes (virusscan, firewall, UAC itself).
Exactly,and normally hardly any program should access them directly.
I haven’t actually run Vista, so excuse my lack of knowledge, but from my point of view, the problem is the not the UAC; it’s the developers.
Due to the poor underpinnings of previous versions of Windows, the developers have been able to screw around with the internals as a short cut to compartmentalising (is that even a word) their applications properly. Now that MS has got the architecture right, they should now be encouraging developers to change their apps to work with it; not giving them an easy way to bypass the work they’ve put into making Vista secure for the average punter.
All this online wailing about the UAC have a common thread to them; it’s all written by geeks; folk who spend all day tweaking their boxes and installing/de-installing applications. Normal folk don’t do that. They install a handful of apps and games, then just leave the system alone. So I’m not convinced that they will be seeing the UAC prompt ‘constantly’, as some pundits would have you believe.
So rather than bypass it, MS should stand firm and force developers to code to the correct spec. Aside from system utilities, does any application really need superuser privileges?
OSX has a UAC, and I hardly ever see the prompt; is that because it is better? Nope (hell, I read a piece a few weeks back, on how any application could easily spoof the MacOSX UAC to trick users into bypassing it). It’s because OSX developers are more disciplined, and are prepared to work that little bit harder to ensure a pleasant user experience. Vista has the APIs in place that should allow developers to produce breathtaking applications that can match/surpass the sort of stuff produced on MacOSX; but I’ll be amazed if we see many developers go the extra mile to take advantage of it.
I have an old Powerbook that I still use for some stuff, and the only app I installed on it that causes the UAC to pop up, is MS Office. Perhaps MS needs to lead by example.
its probably same as DEP, which can programmatically be disabled… by userland programs.
On Linux, what is stopping an application asking you for the root password and then using that information to do something as root?
No different/
The difference is that once you give it the root password it flicks a little switch that says, no other application, including itself ever has to ask for the root password again. They can just always run as root.
And you have no idea that it has done this.
That’s true on *nix as well; a malicious program could set the suid bit (for any file on the system) just as easily.
No matter what system you use, if you grant a program root/Administrator privileges it can do horrible things.
Microsoft is trying to improve security by putting more doors infront of intruders; Is this a real good option? As we all know that a thief can intrude a safe let alone a door if he wants.
Microsoft security engineering really should be revised and totally re-engineered to give us a real powerful security features that steps beyond stopping code destruction but to step to the world of code malfuction prediction and then code healing.
seems the general consensus here is that disaling UAC means automatic elevation, but is that really so?
it’s also possible that disabling UAC means disable the option for on-the-fly privilege elevation. that would make it even SAFER to have UAC disabled.
If you’re logged on as an Administrator and have UAC disabled, all programs [can] run with full privileges.
If you’re logged on as an Administrator with UAC enabled, you must explicitly grant programs elevated privileges for them to run with such.
that sounds silly. the whole point, as far as I can tell, was to work in a reduced-privileged user account, and have UAC to let you quickly and temporarily acquire admin privs when you need them.
if you’re running as admin, your security token already has these privileges. even if they are disabled, it would be a simple API call to enable them. (AdjustTokenPrivileges)
so this bring me back to my original point, that disabling UAC means your limited user account can’t get help from the system to quickly elevate to admin. that’s MORE restriction and MORE security, not less.
that sounds silly. the whole point, as far as I can tell, was to work in a reduced-privileged user account, and have UAC to let you quickly and temporarily acquire admin privs when you need them.
if you’re running as admin, your security token already has these privileges. even if they are disabled, it would be a simple API call to enable them. (AdjustTokenPrivileges)
so this bring me back to my original point, that disabling UAC means your limited user account can’t get help from the system to quickly elevate to admin. that’s MORE restriction and MORE security, not less
You have it exactly backwards. When UAC is in effect, the LSASS strips the privileges (generates a standard user token) and all processes from userint onwards have only standard user privs. Note: the privileges are not actually present on the token, which is totally different than a disabled privilege that is present on the token.
When you launch an application that has (a.) a compat shim (b.) admin flag in its manifest or is manually configured to request admin, the consent UI actually re-authenticates the user and builds a full admin token (using pass through authentication, which is why, unlike runas, you don’t have to provide credentials again). If you disable UAC and login with an admin account, your privs will default to that of a full admin; a far more dangerous situation.
The only difference between running as an Admin with UAC and running as a standard user is that you are not prompted to re-enter credentials when launching an app with elevated permissions, instead you only need to click okay.
-Mak
As always the first user you make (In RC1) is an admin. And for most users that will be the account they use most. So if UAC is cut off you might as well be using Windows XP with a higher price tag!
Don’t run software from untrusted sources with admin priviledges….
Unix systems have made software work with user installations for years. The only times I see it broken is with some bad python install scripts, but generally they all allow user level installs (except for some obvious exceptions like Apache).
Microsoft should strive to do the same with Vista. Give developers a real way to say “I’m not doin’ anything ugly, I just want added convenience for you.”