The topic is "is it bad to turn off user account control?", my answer is NO - it's not bad, BUT there's a catch - you need to use LUA... I, now, will not argue if LUA stop ALL malware or not, I've stated several times, even if you got a nasty keylogger, the keylogger will be locked at your current LUA, it won't go system wide (which is VERY GOOD).
As pparks1 said, if you want to be completely safe, turn off your computer, go play something else...
zzz2496
Let's face it ... there is NOTHING that will completely stop all malware. You can have LUA, UAC, and a high-end AV software; you still need user discretion.
Agree with this 100 percent, if you think UAC is going to save you then you are sadly mistaken. It's more about using compatible and safe programs rather than saving your system. Not even A/V's will save you from some of the exploits that are floating around. UAC is mostly there to save people who know nothing about the programs they are installing, even then it's just too easy to click yes all the time which defeats the purpose of using it. If you want to be completely safe turn off your computer LOL, so true.
Obviously we could go back and forth on this subject all day but I think my original answer was worth defending.
While it may not save you, it may alert you to a strange situation when a known piece of software is attempting to auto elevate itself. This is where I come to rely upon knowing that UAC is in place. Even as a systems admin and a self proclaimed computer nerd...I honestly don't know exactly what every single piece of software is doing on my machine.
This really isn't the intention of UAC. While it might be the result, the intent is to run a Windows computer without being an admin 100% of the time. Previously history in Windows shows that everybody=admin=all the time...doesn't work out so well and you end up with egg on your face at a corporate level with people belittling your software/OS.
Disabling UAC basically results in a return to the Windows XP security model. Here are some consequences of disabling UAC:
a) When using standard account:
- loss of protective benefits of mandatory integrity control using integrity levels, including User Interface Privilege Isolation and Protected Mode of Internet Explorer
- worse application compatibility due to disabling of file and registry virtualization
- loss of UAC prompt when a program isn't working due to lack of admin rights, which lets the user know why the program failed; some programs will give an informative error message at such a failure, but some won't
- loss of ability to elevate programs through UAC
- switching to admin account to do admin activities is more dangerous (see below)
b) When using admin account:
- programs run with full admin token by default, including Internet Explorer
- worse application compatibility due to disabling of file and registry virtualization
- system compromise by malware can be done without any UAC prompt
From New UAC Technologies for Windows Vista:
I use a standard account for everyday tasks, and normally switch to an admin account to do admin-only tasks. I use UAC on its highest setting. For situations in which there is too much inconvenience to switch to an admin account, I launch programs elevated from a standard account without any UAC prompt by using an elevated program launcher - see https://www.sevenforums.com/system-se...-launcher.html for more details.UIPI [User Interface Privilege Isolation] comes into effect for a user who is a member of the administrators group and may be running applications as a standard user (sometimes referred to as a process with a filtered access token) and also processes running with a full administrator access token on the same desktop. UIPI prevents lower privilege processes from accessing higher privilege processes by blocking the behavior listed below.A lower privilege process cannot:
- Perform a window handle validation of higher process privilege.
- SendMessage or PostMessage to higher privilege application windows. These application programming interfaces (APIs) return success but silently drop the window message.
- Use thread hooks to attach to a higher privilege process.
- Use Journal hooks to monitor a higher privilege process.
- Perform dynamic link-library (DLL) injection to a higher privilege process.
With UIPI enabled, the following shared USER resources are still shared between processes at different privilege levels:
- Desktop window, which actually owns the screen surface
- Desktop heap read-only shared memory
- Global atom table
- Clipboard
MrBrian, very nice post... I understand the implications of disabling UAC, I understand many technologies that make up UAC and I'm one of those who won't use UAC. If you read this thread from the start, I posted a link to another thread where I discussed UAC quite lengthy with other members (one of them is pparks1). Yes I know about MIC, UIPI, Registry virtualization, and other virtualization techiques implemented by UAC. Here are my why(s):
- Running everything in standard user with UAC off is faster because all of those so called "security" layers aren't operational, and is not needed because the token which is currently used is a standard user. Why waste processor cycles for useless processes? There are lots and lots of malware that uses social engineering that can "bypass" UAC just like that, why waste processing time if with or without UAC you can catch bad things? MIC, UIPI and so on is there so that if a so called malware wants to install it self silently UAC will catch it, but come on, this is 3+ years since UAC is first introduced, are those malware/virus developers really that stupid?
- IE, don't use it, it's bad for anything - unless your company is depending it's life on it (which is VERY BAD), still dont' use it (argue your boss to move to another safer browser)... No matter what version, as long it's IE, stay away from it (unless MS can prove otherwise in a wide open public test with several hundred thousand testers and tested for at least a year straight). With LUA or not, stay away from IE period.
- Application compatibility has nothing to do with UAC, if a program can't access HKEY_LOCAL _MACHINE, with UAC it won't be able to access it, without UAC it still won't be able to access (with LUA), in both cases - the app will crash. Better for it to crash than to run intermittently. Maybe UAC will tell you something, but how many users will read the darn message? The fact is the app crashed... Should the registry virtualization let you run an app, most of the time that app will crash anyway, unless you run it in XP mode (saves time, blood, tears, and frustration).
- Privilege elevation is still somewhat doable through "Run as..." context menu, too bad this method doesn't behave as transparent as sudo in *nix.
- Once you understand the difference between Admin and Standard user, when you need to do system administration, you login to admin account, do whatever you need (update apps, install new apps [installers has been scanned with AV], update drivers, etc), then log off and use standard user for everything else. You don't use admin to browse the net, especially use IE while in admin account, that's suicidal.
- You can get malware/virus. With UAC enabled or not, you can still get it, with admin + UAC, your virus/malware will infect your whole system in an instant (there are many thread posts that proofs just that). With LUA, the one that's infected is the limited user's files/account, it won't spread to Windows's core. Login to another user (preferably admin) and clean it up.
The basic idea of UAC is to let regular Windows user (those who uses admin account all the time) to be able to practice safe computing without learning anything, that's all there is to it. UAC strips you off your admin privileges and saving you in the process. But for those who understands the basics of how multi user environment works, using UAC + LUA is moot, it checks and do everything to strip you out off something you don't have... It's pointless...
zzz2496
Quote