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

Well, I guess that's one for Duh Magazine... You're right, of course, now I will give myself a dope-slap

 

This is an EXCELLENT thread. It has remained on topic, and I have learned more in 10 minutes than I could have in 3 hours surfing the net looking for info.

 

wow, alot more to UAC than I and the majority of people realise.

I initially came across a article on zdnet which linked to joanna rutkowska's blog and that got me reading about UAC and I eventually came here. One thing for sure the combined reading of all these pages has learnt me a lot.

My initial opinion of UAC was that it provided security in that the admin user was made into a partial limited user (I knew it wasnt a proper limited user) and that made everything by default not have admin priviledges unless approved by UAC. When I tried vista in the past I did find UAC too annoying and restrictive enough in that I toyed with turning UAC off completely and eventually ended up leaving it running but have the auto elevate for the admin user, I had a deep down feeling based on the IE restricted mode that UAC did more than just the prompts which is why I assumed in auto elevation mode UAC was still doing 'something'.

Now I use windows 7 on my laptop and my spare desktop and is planned to use it on my main desktop pc, currently I use an admin account and UAC on its default mode, I have not felt the need to auto elevate in windows 7, so the changes microsoft made to reduce excessive prompts for me have worked.

I am very experienced with FreeBSD and also experienced with some linux distros so I am very aware of the need to avoid using super user accounts for non admin tasks, it is a very fundamental rule that if a process gets compromised then the priviledges of that process are now available to the attacker, if the process runs as a super user then you are owned.

The thing that most widened my eyes was "Software Restriction Policies" That looks a very incredibly powerful feature that I have never heard of until yesterday, it looks to be powerful enough in that alone can remove the need to be running a auto monitoring anti virus software since malware will never be able to execute without user's help. After reading all these articles, forum posts etc. my own conclusion is that the primary purpose of UAC is to allow people to get used to running limited user accounts without having significant problems, unfortenatly with all the marketing tripe coming from microsoft I never got that impression until yesterday.

So previously someone on XP running a LUA would perhaps have to fast user switch to admin every now and then to install drivers, system apps etc. LUA thanks to UAC are more locked down in vista+ due to the integrity levels? eg. IE gets some sort of sandboxing which wouldnt occur in a LUA on XP.

The reccomended practice it seems is to run a LUA, turn of elevation for the LUA, keep UAC enabled for the admin account, enable SRP. I have 2 questions on this however.

1 - is the silly *setup* filename issue that joanna raised on her blog still existing in windows 7 UAC, if it does exist then that means a LUA will have to escalate to run any installer, such as installing a game. If the user switches to admin to install that game then the game will not run under the LUA?
2 - Is using fast user switching fine the same as logging out then logging in as admin, since using fast user switching both users would be logged in at the same time.

 

I agree; I don't use real-time monitoring av, although I do have an on-demand freebie in Malwarebytes. And yes, SRP is very powerful.

I don't agree at all with the paranoias who believe the UAC elevation option should be turned off. Just password it and keep the pw to yourself so others using a standard account can't elevate anyway because they don't know the pw. I guess there is some extremely remote possibility of your lua account getting pwned, as has been discussed, by elevating with UAC, but just use your brains and you'll be fine. Being security consious is one thing but being an extremist will only hamper you from performing day-to-day tasks and, more importantly, stifle your enjoyment in using your pc.

Not totally sure of the question but yes the LUA user would have to elevate to install a program.

It depends on the game, but it should run fine unde the lua account.

I'm not sure, but i have no problems doing this. It is, after all, faster than logging off.

 

Glad you said that, to me a LUA with password elevating when required would be the best way to run things. On occasion where I would know I would be doing something require multiple elevations I then just switch to my admin account.

Joanna made a blog post here detailing a problem.

http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html

However this was for vista so is years ago and the behaviour may now be different, in short her problem with it was this.

In a LUA in XP and I assume in vista with UAC turned off the installer would run under LUA credentials. The algorithm in place for UAC would force any program that has *setup* in the filename to ask for UAC elevation and as such you are then forced to run the installer either as admin credentials or not at all which of course increases risk and would also be a potential showstopper to running a LUA with UAC set as auto deny.

Glad to hear it, with me logging off would be far too much work I often have many apps running for weeks on end and things like reboots (and logout) are a pain as it takes me 5 minutes to start everything back up again.

I do run auto monitoring a/v but I dont like it, there is an impact always whether it be stability or just performance. All these auto monitoring a/v are just trying to cover for a mass utilisation of a insecure way of running an operating system. The solutions I have learned in this thread should be more effective than an a/v can ever hope to be and without the typical downsides of running an a/v. Of course I would keep an a/v for on demand stuff as well as the occasional malwarebytes scan.

 

If you mean in terms of security, this is what Microsoft had to say in Security Best Practice Guidance for Consumers (in Vista):

Also, from Inside Windows Vista User Account Control:

 

1. It's a tad complicated. If you really don't want installer auto-detection, you can turn off UAC, which then can't prompt for elevations and installers will just run with the privileges they have, until they try to do something they don't have privileges for and give you an access denied. Or you can use group policy to disable installer detection and leave UAC on. Installers that have requireAdministrator in their manifest as the requested execution level either will not run at all or likely will not run correctly if they are not elevated. Software that is intended to be installable by non-admins will not have requireAdministrator in their manifest, but will and should use asInvoker (or HighestAvailable) instead and then they will start and run perfectly fine under a limited user account without elevation to higher privileges.

But in short, no, LUA definitely does not need to escalate to admin to run any and all installers. LUA can run installers that do not require admin privileges just fine, regardless of their file names. Only the installers that were made to include requireAdministrator in their manifest will be trouble. But then, those are either poor design by the software developers or for a good reason: for example, if the installer would install drivers or modify system files, it really makes no sense for the installer to run without admin privileges. So, it's actually rather reasonable. Even when such a piece of software, perhaps a game, is installed with admin privileges, it should still run just fine from LUA. The only exceptions to that are a) poorly made software that tries to do things like write to Program Files after installation for no good reason or b) software that is truly intended to do things only admins can do, like change system-wide settings and such.

Then there's also the issue of SRP or AppLocker. If you've got a default-deny type policy for those enabled, then you can't install anything in LUA without elevating to admin. Which is of course the whole idea with such a policy - limited users can't run any software the admin has not approved, whether that be a harmless installer for a nice game or an evil malware. So for folks who use SRP or AppLocker, they'll have to elevate anyway - either by UAC or by FUS / logging out the old-fashioned way.


2. Yes, FUS is effectively the same as logging out of the limited user account and logging in as the admin.

It's not paranoia, though. It's just a statement of fact: UAC elevations are not as secure as the alternative, meaning FUS or logging in as admin the traditional way. It's up to each user to decide what kind of setup they would prefer for themselves. UAC elevations are more convenient, less secure. The differences are not massive, but they exist. For those who prefer convenience, UAC elevations are the better choice. For those who would rather have the increased security, there are other better options. It's all about choices in life!

It's certainly worth noting that we're discussing attacks that are not common in any way, so the threat is small, and there are also ways to mitigate it still further like by using SRP or AppLocker. So, when I say that UAC elevations are less secure than using FUS or logging out, I don't mean to say that UAC elevations are "insecure" as in using them would drop the level of security below the threshold of sufficient and acceptable. What's sufficient is up to each man to decide. I simply mean that if one is really gunning for maximum security like one might in a corporate environment for example or when specifically asking which is more secure, then UAC elevations need to go, because they are not as safe as the alternatives. In other words, I'm not saying everyone should just turn UAC elevations off. I'm saying that those people who want to go for maximal security even at the cost of convenience in their configuration should turn UAC elevations off.

As far as the possible attacks themselves are concerned, it's not the case that your limited user account could be pwned by some attacks against UAC elevations. The case is that you first have to get your LUA pwned, to get some malware running in LUA, and then the malware or attacker can start an attack against UAC elevated apps, and possibly gain admin privileges and own the entire system. So the threat is that exploiting UAC elevations can get the entire system owned, not just the LUA account. But first you have to own the LUA, which is not so easy if the user knows what they're doing, like not running this trojan some evil guy sent you...

For me personally, there are more reasons than the security factor for not using UAC elevations. I just happen to be a fan of very solid separation of roles between admin and normal user. That is to say, when I'm admin that's because I'm doing admin-like things and I really don't want the OS to be asking for my permission whenever I give some command - so I'm the kind of lazy guy who would set UAC for admin accounts to elevate without prompting or even disable it completely. On the other hand, when I'm in a limited user account, I want the OS to just bluntly say no if something, including me, attempts to do something limited users cannot do, like install software system-wide. I don't want it to ask for admin credentials, I just want a nice big fat access denied. Therefore, I would set UAC for non-admin accounts to automatically deny elevation requests. This helps my performance, because I don't get asked stupid questions all the time, things just work as I expect them to work: admins can do admin things without constantly clicking yes, and LUA just does LUA things and will not ask me for admin creds. So that's what I like. What all you guys like may be completely different. To each man his own, and so on. But, when we make our choices, it helps if we have the facts, as in which is more convenient or which is more secure and so on.


Well, now, that was a bit longish from me again. Oops.

 

Absolutely great thread !

Thanks to all participating in it (and a special thanks to Windchild)!

Thanks again all !

 

I realize it's a fact

Yes, and I'm just trying to be the tempering voice of reason when I suggest the use of UAC under LUA to do some administrative-required tasks such as editing network settings, advanced firewall settings or computer management settings, for example, rather than always logging off the LUA, then into the admin to do these rather inocuous tasks. Really, it's plain silly imo to be this drastically cut-throat security consious just because it is the Microsoft way of doing things. You need balance in life, man

Right, thus the reason for my balanced approach.

I played with Applocker a bit last night but it didn't work as I expected. I'll need to read up on it a bit more to understand it better. Maybe SRP is overriding it?? Anyway, no big deal; I'm sure I'll figure it out sooner or later

As I mentioned earlier, why is this an issue if the password needed to escalate is kept from those you don't want to grant escalations to?

This is what I figured and meant by LUA getting pwned first to spearhead an entire-system-pwnage but did not clarify.

Of course, and this is wheare a lot of people, not all mind you, but many should be considered smart enough to use their brains as part of a security arsenal. After all, the lUA account is already providing a near-impenetrable barrier to malware attacks, so a light dusting of basic intelligence should help to make up for the rest.

You are corporate IT management brainwashed

Seems a reasonable approach regarding use of the admin account. I may just also turn off the UAC in my admin account.

So you don't trust yourself? As for installing system-wide from the lUA, I don't promote this either, only to use escallations from lUA to do some routine admin tasks like the ones I mentioned earlier.

True, to each his own but I wager you are spending more time, as I would to, by logging off LUA, then into admin every time you want to conduct some routine admin tasks, unless you are spending a lot more time in the admin account than I do, in which case maybe your approach is best for you, but then it strikes me as also being less secure than mine

No worries Windchild. Your epic posts are expected and people here ought to be used to them by now Keep in mind that even if I oppose some of your highly rigid and corporate methodology, I still hold your technical merit in very high regard and you may even convince me to embrace some of your suggestions

 

Even though I think M$ was smart to finally (20 years late) start forcing the DAC issue (as opposed to making it optional) in Windows, there's not going to be a guarantee that nothing can pwn the machine if it is being run from a LUA. This is the case with *nix and it will be the case with Windows.

The best way to mitigate DAC privilege escalation attacks is to move a step up the ladder from DAC to MAC. In Linux I happen to use AppArmor, though SELinux is probably more popular. AFAIK there is no such system in Windows unless one is to use third party software (even then I am not sure how effective it is). I suppose the closest thing would be AppLocker, though it's not really the same thing. MAC on *nix is somewhat (not exactly) like what M$ did with MIC, though M$ oddly does not allow you to adjust integrity levels (though I understand there are third party hacks out there now). I don't think Windows has anything like MLS though, which can be done with SELinux.

 

A tempering voice of reason never hurts. Certainly, using UAC elevations under LUA to perform some admin tasks without having to log out or switch users is perfectly okay. My only interest in the issue is that people are aware of the fact that said elevations compromise the security boundary that user accounts normally provide. For some this does not matter at all. For some it does matter. I also don't consider the no UAC elevations approach necessarily silly at all. In some cases, it can be silly, yes. But in some cases it can be entirely reasonable.

Because those prompts really can be confusing and annoying as well as waste time in some cases. If I don't know the admin password, why should I be prompted for it, why not just give me an access denied error? And on the other hand, an access denied error message doesn't hijack your whole screen to the secure desktop so that you have to drop everything else that you were doing for the moment to cancel out of the UAC prompt. This is one reason why corporations might want to disable the elevation prompts even for users who wouldn't know the admin credentials needed to elevate: less confusing, hopefully less support calls over why I'm being asked a password that I don't know, a little less time wasted to click out of the UAC prompt. It does save some processor cycles too. The KISS rule could apply here: "Don't ask users questions that they can't answer. If they don't know the admin password, then don't ask them to give it, just say no when something requires it."

Nah, I'm just being practical. I like admins to be able to do admin tasks quickly without questions, and normal users to be unable to do admin tasks especially in a way that compromises security boundaries. This works for me. The great thing is that there are other options for people who find that this doesn't work for them.

It's not that I don't trust myself. It's more that I don't like the attacks that UAC elevations from a limited account make possible. And I also don't like the whole screen hijacking prompt for admin credentials thing, either. A simple access denied error message with that one OK button is preferable to me. Due to how rarely I need admin rights, the loss of convenience is literally zero, especially because in those few cases where I do need admin rights, I will need them for a lot of stuff at the same time (like installing multiple programs and changing multiple settings), which means it's actually more convenient for me to switch to an admin account where I can do all of it quickly without getting a large number of consent or elevation prompts from UAC. It's a combination of personal tastes, efficiency, convenience and security factors. Certainly being logged into an admin account where UAC is disabled or set to automatically elevate without prompting is less secure than having UAC prompt for everything: one might make a mistake that UAC could have prevented. But that's a chance I'm willing to take to get things done faster and in a more comfortable way, knowing that I've not made such mistakes that UAC would have prevented so far.

Obviously there will practically never be a guarantee that nothing can pwn the machine. There won't be such guarantees even with mandatory access control systems, because they are still software and can have vulnerabilities. But sure, MAC is stronger.

MAC is nice and all, but it's a bit pointless in a scenario where most people don't even understand DAC or take advantage of it. Once DAC is used widely, then we can talk about MAC, and how to make that work nicely for the average, uneducated user. Because there is no chance that people who can't or won't cope with DAC would be fine with the far more complicated MAC system.

As for AppLocker, it's not MAC. For MAC systems on Windows, many HIPS products could apply as they apply their restrictions on processes instead of users.

But really, I'm the kind of pessimist who won't talk of faster than light travel before we can put a man on Mars. While I can appreciate using SELinux or AppArmor on a Linux box, I also realize that for many people, this is pretty far away from what is practical for them.

 

So are we saying that when one gives the UAC prompt permission to elevate a specific task from the LUA such as a 3rd party defragger, that we are in danger from attack from all attack vectors in contrast to a narrow vector?

Maybe a visual will help. Imagine a fortress surrounded by 4 walls. Are we saying that allowing elevation from LUA is the equivalent of temporarily knocking down all 4 walls for a limited time?

I was hoping it was the equivalent of letting someone in through the fortress door (narrow vector) while all four walls stayed standing, not taking down all four walls (all attack vectors open).

 

No, the possible attacks against UAC elevations in LUA are very limited, and they are difficult to pull off. Meaning, the threat and the risk is small. But, it's a threat and risk that doesn't exist at all when UAC elevations are not used.

The fortress door idea is pretty good: you can check that there's only one guy in his cart coming through the door, and you already gave him permission. It's just that you're not really sure whether someone just hid inside his cart and is trying to get in the fortress without permission to murder some folks. Actually, maybe you're not even sure that someone didn't just brainwash this poor guy that has permission to pass through the door to start some murdering once he's in the fort. But, it is not at all like all the fortress walls disappeared for a moment so that everyone could just walk right in easily from any direction. So, small risk.

 

Whew, that makes me feel much better. Thanks for the clear explanation.

Such a small risk I can live with compared to driving the interstate.

 

Perhaps an analogy to the risks involved:

you hop in your car to drive to the local supermarket and you run the risk of getting smoked in the driver's side by a cement truck while crossing the intersection, but of course if you're even a half competent driver, paying attention and not drunk or stoned at the wheel, it ain't likely to happen, but it can - it's a fact As long as you don't let the conveyed risks spook you too much, and you employ a solid (no need to get anal retentive) security approach and balance that with some convenience measures on your pc, you can actually enjoy doing things on your computer without allowing yourself to be possessed by the prospect of these unlikely malware attacks happening to you.

BTW, for a nice safety net that is practically fool-proof if you haven't already done so, employ an image/restore strategy, backing up to two different physical locations so that in the unlikely event of infection or some other catastrophic event, just restore your backup in a matter of mere minutes and *poof*...problem solved

 

Yes, it's good to remember that there's a great difference between what is possible and what is worth worrying about. Just because some kind of attack is possible doesn't mean you should worry about it. When designing security for our homes, probably none of us worry about heavily armed special forces storming the place at 24:00 zulu when we sleep, even though that's possible. Someone involved in planning terrorist attacks or such things might want to consider that possibility, though.

Technical discussions on security are important. Some knowledge about the technology, its limitations, benefits and possible attacks against it is required to create a reasonable security policy. One just needs to keep a cool head and stick to realism. "Perfect security" (invulnerable against everything) is not possible, but "enough security" (strong against the most likely threats) is. So, one really just needs to understand what the most likely threats are and why, and how to counter them with technology and thinking. Special forces won't raid your house because you're uninteresting to them. A burglar might, because their time is not as expensive, and your wallet and nice big screen tv are worth something to him. It's easy to get a bit too worried about things, reading about vulnerabilities or comparing AV detection rates or wondering whether LUA is better with or without UAC. Or to quote Bruce Schneier: "Talking about security can lead to anxiety, panic and dread... Or cool assessments, common sense and practical thinking."

Backing up is absolutely one of the most important things to many users (those who store important data on their systems, less to those who don't). And it's easy to forget when thinking about all the malware and exploits and what not. But no AV or HIPS or LUA will protect your data from a broken hard drive, but regular back ups may save the day.

 

Yep, wouldn't be caught without my system images.

 

yes I thank you to windchild as well as everyone else who has contributed to this thread, its the most information filled forum thread I have read on the internet for quite a while.

I plan to put windows 7 RTM on my test box today or tommorow, then I will setup a LUA environment with SRP and put some software on that I use in my everyday enviromnent and and see if I hit any problems. As it stands now I expect I will keep UAC elevations on for the LUA (I do see why one would turn off for sure in a corporate envrionment) since I am the admin using the LUA it makes sense to me, for the admin account if its the case I am only using it for installers and system maintenance then I may well set UAC to auto elevate on it.

I am quite excited about this, something new to do and gives me motivation to spend time configuring my pc's again. I have never felt quite safe with simply running an anti virus, I have always felt properly running the OS in a secure manner is far more important.

 

LUA or UAC or SRP I forget which one prevents executables from running.

My questions what types of executables files does it prevent from running?

 

SRP prevents executables from running in places other than the Windows and Program Files directories. The basic idea is that you can execute something where you have no write privileges and where you have write privileges you can't execute anything.

You can set it to deny all software files or all software files excluding .dll files. In gpedit.msc you have to first create the rules, which is simple to do. Then you can see a list of executables that are blocked. You can add more to the list if you like or delete some. Deleting .lnk from the list is a good idea, for example. Here's a pretty good article on this.

 

arran, if you have the Win 7 Ultimate RTM, check out AppLocker under Local Security policies; it's pretty awesome and a lot easier to configure rules (auto-generate is possible) for than SRP. You have to start the Application identity service for it to work, and keep the service at Manual until you are confident AppLocker rules are set up correctly.

 

SRP is outdated, at least on Win 7. You should use AppLocker if you have the Enterprise or Ultimate edition.

I have AppLocker setup on my 7 test box and the other day I was trying to update my car gps nav system and AppLocker refused to let me run the software even though I was running it as admin! I only have a select few publisher rules allowed and everything else is disallowed (white listing approach). So, when AppLocker saw TomTom it didn't recognize it as a publisher I had allowed and I got the "blocked by group policy" message.

So, the lesson is when you lock something with AppLocker it won't even allow the admin to perform the action. This is sort of like a Mandatory Access Control system (root isn't all powerful any more), though it's not exactly the same and has a somewhat different purpose.

The nice thing about AppLocker is the publisher rules. SRP doesn't have this and is the reason many enterprises do not use it. And the rules can be applied to .exe's, Windows installer files, as well as all forms of scripts.

 

You maybe already know this but you could create the default rules or, better yet, use the Automatically Generate Rules... option which will create Publisher rules for your signed apps, and hash rules for unsigned apps. Your whitelist approach is extremely Fort Knox defensive, for sure - LOL, but could cause some occasional grief when you do need to run certain legitimate programs. Having used AppLocker since only last night, it appears to be powerful! Properly configured I see no chance of a standard user having a hope in He11 of incurring a malware breech

 

AppLocker is very nice. But about your experience with installing TomTom in the admin account with AppLocker enabled, I would point out that the default rules for AppLocker allow admins to execute any file, signed or unsigned, no matter where it is and where it came from, script or Windows installer or normal PE executable. So, "normally", the admin account will remain largely all-powerful unless the default rules are changed or are never created for some reason. Personally, I find it convenient to allow admins to execute anything, although it clearly is less secure than applying restrictions to admins as well.

 

The default rule for the BUILTIN\Administrator (created during the Windows installation procedure) to execute any file path= * is not the same as the Windows logged-in admin account (machinename\admin) you might create for yourself. The former is the more powerful, all-encompassing "God-like" account. For example, I had to create a rule for my Windows admin account to access the nVidia control panel under the Windows folder, after I had changed the user access for the rule from Everyone to one of the User account names. I've set it up so that only that Standard account (mine) and my Windows admiin account can access it. The other two standard accounts my kids use, can't.