Limited User Account (LUA) and highest UAC level overkill?

I've always used Vista and W7 as a limited user (non-admin) with the UAC turned to highest, most secure setting in W7. I'm starting to wonder if this isn't overkill.

Wouldn't running as a LUA prevent rogue apps from installing to the system drive without the need for UAC prompts by turning down the UAC prompt level to its lowest setting?

Conversely, I could run W7 as an admin with UAC set to its highest setting, as anything that would attempt to install itself would prompt me with a dimmed desktop anyway.

After I think about it, maxing UAC security OR running as a limited user should suffice for security purposes without the need to employ BOTH security measures, no?

 

Sounds good to me.

 

What sounds good? One or the other or both?

 

If the computer is behind an reputable Firewall Router, by security standards it should be, then:
maxing UAC security OR running as an limited user should suffice for security purposes without the need to employ BOTH security measures.


HKEY1952

 

I use a standard user account and highest UAC level in windows 7.
I dont see a problem with that.

 

Personally I would stick to the LUA regardless of how you decide to configure UAC. Microsoft themselves say that UAC isn't a security application, but rather a means to get certain developers to finally make their crapware applications LUA-compliant.

There's a thread about UAC being by-passed by 8 out of 10 malware samples. I think your LUA is the best bet, having UAC turned on is certainly not going to hurt anything (unless you find the pop-ups annoying).

 

OK, thanks for replies. It seems to be the consensus that running is LUA is genuinely a good security practice, immaterial of UAC status. And, when running W7 as a limited user, UAC prompts pretty much exist solely as a convenience factor amongst other things (folder virtualization, etc.).

Playing around with the UAC slider within the LUA, it appears that only the two highest settings can be used, unless UAC is disabled full throttle, in which case, I would be forced to switch to my admin account in order to install applications. Do I have this right? Or, are there any unforeseen benefits to disabling UAC while running as a limited user?

 

Well, currently, in a standard user account, security can be decreased when allowing UAC prompt elevations for tasks requiring admin rights instead of switching to the admin account (via Fast User Switching, for example) to perform those tasks. (Security is arguably increased utilizing UAC from an admin account.) Malware can compromise an elevated process or provide fake UAC prompts which would allow it past the security boundary that running from a standard account provides.

Protected Mode IE would be disabled. (Note: Protected Mode is not a security boundary, which is not to say that it can't provide some protection against drive-by downloads today.)

 

I don't read this from the article at all. I think the article reinforces the notion that UAC simply raises the barrier (ever so slightly) for malware, but exists primarily as a convenience and that it's relatively easy for malware to bypass UAC's elevation scheme. However, I don't read that it would be safer to 'fast user switch' to the admin account to perform admin functions, which could otherwise be accomplished in the user environment with rights elevation. If that were the case, why would most security gurus recommend running as a limited user?

 

Neither do I. This quote from the article kind of sums it up for me:

"Russinovich stressed that UAC's fundamental contribution is to make it possible (in most cases) to run as standard user to protect the system and other users on the system."

What version of Windows 7 do you have? If you have Professional or Ultimate or whatever versions have the group policies editor you can set up a software restriction policy which will increase your security even more in conjunction with an LUA. See this article for more info.

If you have a version without the group policies editor you can still do it. Lucy and tlu posted some good info on this in a thread here, you can probably find it using the search.

 

The link in the post you quoted from was to an article only explaining how malware can bypass UAC. That was intentional. I thought the explanation for not using UAC in order to increase security in a standard account was obvious. Mark Russinovich's explanation below is more clear I hope.

From Inside Windows Vista User Account Control: (Boldface emphasis is mine.)

See also Security Features vs. Convenience. (Jim Allchin's similar advice is in the last few paragraphs.)

 

Huh. I must have glossed over that part. I haven't before come accross anything which would suggest performing admin tasks logged on as an admin would be any more secure than performing those same tasks logged on a limited user with elevated rights. The malware referred to in the article that could live in the user environment and which could elevate itself by bypassing any UAC barrier could just as easily do the same (perhaps easier?) in the admin environment.

I just don't understand the logic of fast user switching from a security perspective when you have the convenience of UAC.

EDIT: OK, what I think the authors are trying to say is that quite often the UAC prompt is used as a vector for malware to execute their code, and in that light, it would be better to perform admin tasks in the admin environment with UAC disabled and run normal tasks in the user environment without the possible elevation of rights imparted by UAC.

 

It is safer to use Fast User Switching when you need admin privileges. When you don't need admin privileges, it's safer to use a limited user account. That's in fact what I do (well, not really - instead of FUS, I just log out completely, and log in as the admin to do what I need to do, and then log back to my limited user account). The reasons are simple. From: http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

That's standard case of affairs in multi-user operating systems: elevating privileges always involves risk. It's a convenience thing, not a security thing. See sudo timeout for example. For convenience, it's great to be able to UAC elevate. For security, it's not. It is safer to just log in to the admin account to do admin business, instead of elevating random processes from a non-privileged account.

Because it's safer. It works like this:
- Being a limited user during your daily tasks like word processing and web browsing is safer than being an admin, because limited users have limited access to the system and therefore can only do limited damage, even when infected by malware.
- But when you have a legit need for admin level access, the situation becomes more complex. If you have a habit of "elevating" some process to admin privileges from your limited user account, you may open yourself to attacks like those mentioned above. Therefore, when you need admin rights, it is safer to actually log out of the limited user account and log in as admin, which makes those attacks impossible.
- Now obviously you have to be careful when you are admin - don't execute malware. But you should know that already anyway, so there should be no problem. Just do whatever admin tasks you needed to do, and then log out and get back to your limited user account.

In short, 'security gurus' recommend "using a limited user account for daily tasks, and logging in as admin to do admin tasks". They don't recommend "using a limited user account for everything, including admin tasks through the use of UAC elevations / RunAs." Or, like Mark Russinovich put it in the linked article: "Users wanting the guarantees of a security boundary can trade off convenience by using a standard user account for daily tasks and Fast User Switching (FUS) to a dedicated administrator account to perform administrative operations."

The malware could only do that if it was already running in the admin account. That is to say, something would have to first start the malware in the admin account before it could do anything. Of course, at the point when malware is running in an admin account, whether UAC admin or no, the system can be owned (unless the malware is just stupid, and it often is). But the question is, how would the malware run in the admin account? How would it get there? Who would execute it and why? That's the point. If you use a limited user account for browsing the web and opening email attachments and other risky business where you are likely to come into contact with malware, then any malware infections you get would stay in the limited user account and could not affect the system and the admin account(s) - assuming no privilege escalation vulnerability is involved, but those can be and are patched. Such malware may be running in your limited user account, but if you log in as admin to do admin tasks instead of using UAC elevations from the limited user account, there's nothing the malware can do to get admin privileges - the attacks one can use against elevated processes aren't possible. So all you need to do in the admin account is to not execute anything that is malware, and you will have avoided these problems. So, when you run that installer for some program you wanted to install, be sure it's really legit, and don't go doing P2P or surfing the web while logged in as admin.

Convenience is usually the opposite of security: it is very convenient to keep your door locks always open so you never have to use your keys to open them, but it is not as secure as keeping the doors locked.

Well, no. The UAC prompt is just something the system gives you to tell you something wants elevated privileges. That something may or may not be malware, and it's up to us to tell the difference. Another possibility is a fake UAC prompt: nothing stops a malware from imitating a UAC elevation prompt and asking for your admin credentials, and if you fall for it, then the malware wins.

There's no security reason to disable UAC for admin accounts. Admin accounts are already admin and are supposed to be, and UAC in fact makes them a little safer by creating an alternative limited user token for the admin accounts. In fact admin accounts with UAC are safer than admin accounts without UAC. Of course, there's the convenience thing here again: admin accounts with UAC are less convenient but safer than admin accounts without UAC (obviously because the former makes admins kinda-sorta-limited-user and gives elevation prompts that may block some malicious actions, but the latter just approves anything and everything without questions asked with full admin privileges).

Doing UAC elevations from limited user accounts, on the other hand, is less secure than not doing UAC elevations from limited user accounts. So, if you want to go for maximal security, just set UAC to "Automatically deny elevation requests" for limited/standard users in group policy and you'll never get UAC prompts in limited user accounts anymore. UAC won't be disabled, so registry and file system virtualization will still work, but you won't be able to use UAC elevations anymore and there will be no annoying prompts for admin creds - just "access denied" messages when something really, really wants admin rights.


That was a bit long, but hopefully it clarified things.

 

Fantastic. That is one of the best reads on UAC I've come across. Thanks and bookmarked. Aside from the benefits of registry integrity and folder virtualization, the usage of elevation rights, with which UAC has become almost synonomous, actually raises one's exposure to the execution of malware. I think I originally posed the question with the false notion that somehow disabling UAC from running within the limited user account would allow me to make system-wide changes and install applications without having to input credentials each time. However, that is not the case, as one would still have to have admin credentials to do those things. What steered me in the wrong direction was when people were claiming that it would be sufficient from a security perspective to run either as a limited user with UAC disabled -or- run as a full-time admin -with- UAC enabled, as if UAC somehow could act as a surrogate from running full-time in the user environment.

 

Yes, it's a good read - as a general rule, anything written by Mark Russinovich of Sysinternals/Winternals/Microsoft fame is likely to be worth reading, twice! I noticed that Dogbiscuit had already posted that article, but I thought it wouldn't hurt doing it again since it's such a good one.

Yes, if we're looking at a standard/limited user account, then UAC increases convenience but decreases security - UAC makes it easier for the limited user to elevate a process to admin, but also easier for the malware. UAC is only a security improvement in the sense that it makes the default admin account a "Protected Administrator" account with UAC, what I like to call a "kind-of limited user but not really."

It's unfortunate that many people have gotten the idea that UAC makes admin accounts as safe to use as real limited user accounts, from reading articles and such that tout UAC as a security feature when it's really much more effective as a way to make old and upcoming software compatible with limited user accounts. It's open to debate whether a UAC protected admin account is sufficient in terms of security - that depends on the desires and skills, as well as luck, of the user - but it's absolutely certain that it's not as secure as a limited user account. For highest security, one should use a limited user account with UAC elevations turned off - the automatically deny setting in group policy. But limited user accounts with UAC elevations enabled are still far safer than admin accounts with UAC. So, the UAC admin accounts certainly cannot replace real limited user accounts in terms of security.

UAC is kind of a complicated topic, because so many have come to think of it as just those elevation prompts when it really is much more and due to how the media has portrayed it as a big security feature.

This is a little off topic, but if you're interested in "overkill" in terms of security, as Johnny123 suggested earlier, you might be interested in trying Software Restriction Policies or AppLocker if available in your Windows version. There's lots of talk about those in this forum, as they can be used to create a default-deny situation where limited users can only run programs approved and installed by the admin. That can be used to prevent limited user accounts from becoming infected with the kind of malware that doesn't need admin rights to work - and those will get more common as Vista and 7 take over from XP. There's a loss of some convenience as always with increased security, but to many it's worth it.

 

Very informative Thread about the Microsoft Windows User Account Control (UAC) and the Limited User Account (LUA) and how to employ each for maximum security.


HKEY1952

 

Funny that we are getting discussions about these limited rights implementation after the launch of a new windows OS.

I think you either run LUA or run some form of UAC with a deny execute SRP


For the latter there is the secpol option of the PRO/Ultimate versions of the OS, people with basic or premium versions can use sully's PGS to implement deny execute Software Restriction Policy

XP + Surun = UAC prompt when program elevates, with remember option

Vista + Norton UAC tool = UAC prompts for everything, Norton UAC provides remember option.

Windows 7: UAC Don't notify when I make changes

 

Not really, at the end of the day it's still default admin with UAC as an alibi privilege limiter. As seen in that other thread about 8 out 10 malware samples circumventing UAC, the usefulness of it as a security feature is highly questionable, but that's just my opinion.

I'm also uncertain that UAC will inspire too many developers to make their apps LUA compatible. All they have to do is click the UAC prompt, so why change anything?

Why either or? I have both, works just fine. Also kafu.exe and DEP and no malware. I do scan every once in a while with Malwarebytes, SuperAntiSpyware and AVZ and they never find anything. This of course doesn't take into account the little digital gremlins placed on the system by Command and Control from Alpha Centauri that System Junkie warns us about

Yes and no. SuRun detects some apps as wanting admin privileges, in which case you get the secure desktop gizmo. Some it doesn't detect, then you get an error message or limited function.

SuRun also offers quite a few things that UAC doesn't, such as the various context menu items, control panel as admin and the configurability.

 

Because UAC prompts annoy people and the developers don't want their customers to be annoyed. I think we've all heard the complaints about UAC and all the tips on how to make the annoying UAC go away. More and more software now works correctly in LUA without tweaking, and that is largely due to UAC. So it seems that developers really have been "inspired" - well, more like forced, but if that's what it takes... There's still much work left for many devs to do for better LUA compatibility, but there has already been improvement. I think UAC has served its compatibility purpose nicely so far, although it still causes slow progress as compared to replacing the default admin account created during installation with a real limited user account, with no UAC virtualization or anything. But I think UAC has deserved some credit. It's not a big security feature and should not be relied upon in any way for that purpose, but it is helping LUA compatibility.

 

I like UAC in Win 7 (just installed x64 a few days ago, but need to upgrade from 2-4 GB RAM, and although cheaper now, I'm not sure I want to fork out the $$ for this memory ). For my purposes it serves perfectly as a convenience feature in my standard account, similar to that of Surun in Vista, for editing advanced fw rules, advanced performance mods, network adapter mods, or whatever. As Windchild recommends, I do log off standard account, into admin and install programs from there - always. I'm not overly concerned about potential security breeches with UAC either; there's probably not enough focus on its benefits as opposed to all that's being placed on its weaknesses.

 

How about this one? Mark Russinovich, 2009, July.

http://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx?rss_fdn=TNTopNewInfo

 

Yeah, I missed the date so I edited my post, but a little too late for your response Still, there are other articles that might shed some new light on this subject, such as the Engineering Windows 7 blog, and might help to ease concerns some people have about UAC.

Forgot to mention, I'm running combined SRP with default maximum level UAC in a standard account.

 

To obtain minimum policy protection. Reading this text, seemed like I did not agree with LUA + SRP, that is not the case.

Since you are a LUA + SRP fan, here is some more

When you run LUA it is better to remove access rights of LUA user from a set of HKEY_CURRENT_USER registry keys. KAFU.exe is a nice start, but there are many more. Try find some old post of Tony Klein, or Google for "where malware hides" or install some HIPS programs and look what they protect in the User Hive and User Space

With FAJOXPSE you can add addition access rules on registries/files

 

If one uses LUA and SRP or AppLocker, the value of Kafu and the like is questionable, though. Because if you've already got a default-deny going on, it doesn't rightly matter what HKCU run keys or other autostarts are created, because the programs they will try to autostart won't be allowed to execute anyway unless they were whitelisted by the admin... And then there's also the loss of convenience factor: what if you actually want to be able to run programs automatically when you log on? But on the other hand, if one is in the habit of installing programs that always want to create autostarts for themselves and don't give users installation options that don't create such autostarts (QuickTime is one example of a program like this), then blocking write access for autostart locations will prevent those annoying autostarts from even being created.

 

OK, but what do you mean by minimum policy protection? I don't understand that one.

I wouldn't go so far as to say I'm a "fan", but the features are there, why not use them? It also makes things simpler for me. In contrast to quite a few here, I don't really like playing with security apps, especially firewalls

Here's a rather large posting by Tony Klein on this, thanks for the tip. I'd probably need a couple of days to go through that and (maybe) understand half of it

BTW, have you ever tried this out? It's freeware from a-squared called HiJackFree. Looks like it might be useful if it does what it says on the tin.