LUA questions

First, I'd like to apologize for the selection of the forum. I couldn't find any more fitting forum for this.

I have been running as admin and moved to using protected admin with Windows Vista. Continued the same behaviour with Windows 7. But now I'm building a new computer and after reading good things about LUA + SRP combination which many people here seem to use, I have thought that maybe it is time to start using Standard User for day-to-day tasks.

My questions are: Will I be able to install new software or even drivers with Standard User, if I give the Admin account credentials? Is there any difference on this matter as opposed to the Protected Admin? If I'm able to do it, will it install the software for my Standard User or my Admin account? I mean that sometimes installers ask that who you want to install the software for, yourself or all users on this computer, so I'd like to know that if I choose "yourself", does it mean the Standard Account which I'm using or the Admin which's credentials I gave for the installation?

 

When installing Windows make sure to create two accounts (at least): 1. Administrator 2. Standard.

When you install using admin credentials from the Standard account, it will install the software as if you are installing it from the admin account, so if it asks you "for this user only", it will mean the admin account. Yes, you can install programs or drivers using admin credentials from the standard account.

 

Thank you, I couldn't find definite answer anywhere else!

I think that Windows could get this a little better and tell the installer that the Standard User is installing the program and only give it Admin rights, but I'll just have to make do.

 

With UAC on, or SRP applied to admins, you don't need LUA. UAC will lower the rights of most programs, causing them to be affected by SRP.

 

SuRun does exactly that.

 

Could you specify? You mean that I would be ok running as Protected Admin, when SRP is applied to all users? Will it cause problems for the admin when SRP is applied to it too?

I'll look into that, thank you! =)

 

Even when SRP isn't applied to admins, UAC limited programs will not run outside of your whitelist. That's because UAC runs them under limited rights.
The processes that run with admin rights are prompted by UAC, and won't be affected by SRP. They can run outside of your whitelist.

If you enable SRP for all users, even admins, then nothing outside of your whitelist will run, regardless of what rights it has.

 

Errr..I don't think you are correct at all in that statement. Hopefully one of the LUA experts can comment on this. I recall threads where it was clearly stated that UAC is not a replacement for LUA...something about UAC not being a security boundary.

 

I think you need to read more diligently, and try it out yourself.

UAC isn't a replacement, it complements limited users and admins. Of course it's a security boundary, whoever says otherwise obviously hasn't got their facts straight.

 

This is a debate that has happened a few times on Wilders, i.e. is UAC on the same as running LUA and the answer has always been "no" (at least it was still "no" the last time I read a thread on it). SRP will of course apply to the admin account if UAC is on. Oh, and I do run LUA+SRP in Win7. I would not run as admin (UAC) + SRP for the reasons discussed previously on Wilders. I'm no expert on this, just following the outcome the previous discussions on this subject.

 

I think this needs opinions and raw data from multiple attendees. Has Microsoft clarified which are the differences between Protected Admin and Standard User, apart from the credential window?

 

http://blogs.msdn.com/b/e7/archive/2009/02/05/update-on-uac.aspx

From this MSDN Blog by Jon Davaan, SVP of Windows Development (my bold):

One important thing to know is that UAC is not a security boundary. UAC helps people be more secure, but it is not a cure all. UAC helps most by being the prompt before software is installed. This part of UAC is in full force when the “Notify me only when…” setting is used. UAC also prompts for other system wide changes that require administrator privileges which, considered in the abstract, would seem to be an effective counter-measure to malware after it is running, but the practical experience is that its effect is limited. For example, clever malware will avoid operations that require elevation. There are other human behavior factors which were discussed in our earlier blog posts (post #1 and post #2).
UAC also helps software developers improve their programs to run without requiring administrator privileges. The most effective way to secure a system against malware is to run with standard user privileges. As more software works well without administrator privileges, more people will run as standard user. We expect that anyone responsible for a set of Windows 7 machines (such as IT Administrators or the family helpdesk worker (like me!)) will administer them to use standard user accounts. The recent feedback has noted explicitly that running as standard user works well. Administrators also have Group Policy at their disposal to enforce the UAC setting to “Always Notify” if they choose to manage their machines with administrator accounts instead of standard user accounts.

 

How can it not be a security boundary if it helps people be more secure? That article needs editing.

As I said, UAC is a great complement to any user. It can easily lower rights for admin, and elevate rights for standard users. Also, other software depend on it for sandboxing (IE Protected Mode), protecting settings (AVG, ESET, MSE, WD, WF, etc), and more.

 

It does create certain security boundaries, but it's not a security tool. Maybe that's what the author meant... He just lacked the right word.

 

I don't know how SRP affects UAC-influenced processes in an administrative account, but UAC does, indeed, as J_L states above, limit the rights of applications that do not perform administrative tasks run under an admin account by applying a Standard user token to them.

-http://www.wilderssecurity.com/showpost.php?p=1825485&postcount=5

-http://technet.microsoft.com/en-us/library/dd835561%28WS.10%29.aspx

 

This has been hashed over and over and over. There are many articles like the one scoobs posted that say the same thing - it is not a security boundry.

But, as you probably think to yourself, what do you call it then, as it does lend to better overall security! And I would agree, partly.

To me, (others and I have had to agree to disagree about this ) UAC is a feature M$ had to put in if they ever wanted to get users to exist in a LUA. Its job is simple - prompt the user when something needs elevated. The user is presented with a prompt for "trusted" M$ actions (like changing password) and a different one for something like installing a driver. An informed user would note the difference, which could be helpful to deter a potential unwanted activity.

But, what is this really doing? Why is a feature that makes it "easy" for the novice users to exist in LUA considered a security boundry? Why is a one-click feature to allow pretty much anything considered security? Simply because you must say "OK" now instead of just doing it? And if you don't know the answers to UAC, and just click "OK" because you want things to "just work", is that called a security boundry? (and most people just hit OK when prompted)

This makes me wonder anyway, how come prior to Vista and UAC, LUA was considered about as secure as you were going to get? In NT/2K/XP there was no helping tool that let the user elevate processes. You had to logout/login or use a RunAs. Now UAC offers a super easy way for anyone to use Admin credentials at any point simply by clicking "OK". That is "more" secure?

I just don't see how it is any more secure than simply logging in as a USER, and having to RunAs or logoff to do things as ADMIN. I think it is less secure. But, thankfully the world does not see everything the same as me, else we all might be posting very long statements here

I think UAC can be a good tool to help people, but only those that have moved beyond the "simply click OK" stage of things. For more advanced users, it can be an even better tool because of how convenient it is with a two-button answer. Erm, maybe some food for thought for someone

Sul.

EDIT: I think they should have focused on Integrity Levels as the "star of the show" instead of UAC. Integrity Levels bring much more security wise to the table than an easier RunAs does (meaning UAC).

EDIT (again): And when I think about it further, if you use UAC with prompt for credentials or you use SUA instead of LUA, you have the real deal. I wonder, why would having both Admin token and User token under the same account be considered better security? It seems to me it is simply more convenient, whereas SUA with UAC to help would be more like better security, even though UAC is still only providing a convenience over the standard RunAs prompt.

Thats it, I am done now

 

UAC run at default or, better yet, maximum, helps secure (at least somewhat) the administrator account because applications are running at Standard user level with the standard token. Most people refuse to run under a Standard account, so as long as they're going to stubbornly run as admin, isn't this at least better than running as admin without UAC? At least the browser, for example, is running with only Standard privileges.

Even with using integrity levels, ICACLS, 1846 trick or whatever other security tricks are available, as long as a user has or can gain administrative privileges, they can ultimately elevate themselves above and beyond all that security anyway if they want or need to. It really comes down to employing common sense and controlled behavior by ensuring crap isn't installed (as Mrk, aka Igor Ljubuncic, would say ).

 

"Security boundaries" and "Security tools" have no meaning outside of one's own security strategy, thus, have to be defined from within that context.

From my point of view, UAC as a 'security boundry' would be worthless because the boundary is too far inside the gate. That is, any unauthorized executable can run inside User Space and UAC doesn't make a peep as long as the executable doesn't want to intrude past the boundry into System Space. To wit:

SpyEye, the infostealing trojan leader
http://www.prevx.com/blog/168/SpyEye-the-infostealing-trojan-leader.html

The "security boundry" should be the outer perimeter, and it seems that the OP does in fact have the outer perimeter secured with SRP:

This would prevent any unauthorized executable, SpyEye or whatever, from running in the first place.

regards,

-rich

 

Is it better?

It is my opinion that the only thing "better" about it (for the average user) is that the shell runs with a reduced token. This alone keeps certain undesirable things from happening.

However, if one uses UAC, all you need to do is say "OK" on a UAC prompt to elevate the process to full rights. So, is running as Admin/LUA with UAC on really any different than running as Admin without UAC at all? Of course technically it is different, but if the average user clicks "OK" to everything anyway, there really isn't much difference. The real difference is that you get to see the prompt that "you should not have clicked OK on". LOL, I have heard that many times!

Now, ask that same question about most of those who frequent this forum, and the answer is completely different! UAC does make it easy to be a hybrid admin-user. It is effective at helping the user elevate to admin easily, exactly as it was designed.

If there were no UAC, and M$ decided to quit making Admin accounts by default, would the majority learn how to logoff/login or use RunAs? I have no doubt they would be more secure if they were forced to, but I don't believe for a minute that would happen. The majority would create admin accounts because that way they don't have to learn anything, just click and go. And this what they want it seems.

Experience since Vista came out has shown me that there are those who use UAC and pay attention to it and those who just click "OK" every time. Those who attempt to understand what UAC is telling them seem to fare pretty well from what I have seen. Even though it was not explicitly designed to be a security barrier, it does have that effect because these type of users pay attention to it. However, the other type of user who just click "OK", I can honestly say the only differences I note in infections etc is that you don't have the Blaster type issues with Vista/7 nearly as much - the OS is not as riddled with holes it seems. But, there seems to be no difference in malware and other nasties where all it takes is a simple "OK" to a UAC prompt.

Sul.

 

Even for those happy-clickers, UAC does make a difference due to limiting most executables (ones without shield icon) and Internet Explorer Protected Mode.

 

I agree with Sully, when Microsoft dropped run as basic user in the SRP of Windows 7, they should have focussed on the option to assign medium rights integrity rights to processes not needing elevation.

The problem is Microsoft does not allow the user to change the rights of some programs. Advantage of assigning with icacls is that the process does not prompt for elevation anymore, but stays in LUA

The best work around so far is to set a key 'RUNASINVOKER', for a specific program. It only works for x32 processes. When you use process explorer you will see Windows virtualises them.

For me the advantage of a lot of freeware and virtualising internet facing programs (and containing them in a low rights world) made me prefer x32 Windows 7 ultimate above x64 (taking the disadvantage of loosing 1 GB of Memory and not having kernel protection for granted). Only my son has x64 home editions on his gaming box and his university laptop, for the gaming box I can understand x64 OS (more memory than 4 GB to be used), for the laptop I see reason to choose x64. Son's laptop of same brand with same 7200 RPM harddisk (2,13 GB dual core CPU with 3MB cache) and stronger GPU is noteciably slower than my wife's laptop (dual core CPU @2 GB hz with 2MB cache on x32).

Regards Kees

 

I think it can make a difference, yes. I also think that there is a percentage that has most likely escaped some problems due to the different mechanisms in Vista/7.

I guess I look at it like this:

If I want to spawn a snap-in like secpol.msc, I would want UAC to recognize this is an approved executable and perhaps give me a quick "you must run this as admin" type prompt, just so I know in fact I initiated this process and I want to allow it. That is cool part of UAC to me.

Next, as you state, something without a shield may not spawn UAC and I must RunAsAdministrator. This too is fine to me.

However, what do you do about programs that use a manifest to RunAsAdministrator? UAC recongizes this, and prompts you to allow or deny the execution. This is a double edged sword IMO. On one hand it is nice to have the program communicate to UAC that it needs to be raised to admin rights. This makes it easy and convenient to be sure. But on the other hand, any malicious program can also ask for the same rights. And that is where the 'gotcha' is. This is where I find people who get hit with nasties take the fall. UAC came up, and guess what they did, they said OK.

It is true then, that IE is in protected mode. But that can also be achieved with Inegrity Levels or a simple DropMyRights approach. It is ambiguous to me. I don't really hesitate to tell people to stay in UAC, I mean it makes no sense for them to be full blown admins usually. But I also don't trust them to use UAC in a manner that is really that helpful to them. I fully expect them to call me up one day and say "my computer is messed up". It is what has happened thus far with UAC on, and it is what will still happen because it really isn't a security barrier unless you know enough to make it a barrier. LOL, of course that is true of any security setup. I simply think UAC is often seen as this great new security feature of Vista/7, and how much better users are because of it, but I just don't see that. Instead, I see it taking longer for a problem to develop, but the problem develops none the less.

It doesn't really matter I suppose, as for the people who UAC offers little security for are also not going to be any better off with Sandboxie or AVs or HIPS or Firewall suites. In fact, many of them are fine when I setup a standard LUA (basically what is now referred to as SUA) in terms of being secure, but they simply hate it because they have to actually learn a little bit to properly adminstrate thier own computer. So UAC makes it easy for them to be a user, but also allows them to easily bypass LUA and give root to whatever it is they are trying to execute. A no win situation, yet again.

Sul.

 

I wish I could hack the stupid message one gets when you only allow signed programs to elevate in something like "Computer says NO . . ."

 

When I had security boundaries in mind, I was thinking about the fact that it forces IE8/IE9 to run in Protected Mode (a.k.a low integrity level).

Without it, IE would run either with full medium integrity level or with high integrity level, a.k.a administrative rights.

Obviously, if the infection isn't able to bypass it (UAC), then it will create a boundary between user space and system space. (If we think of an administrator account.)

 

Yes, better but not best. Best would be Standard user with UAC, where only the responsible administrator of the computer knows the password.

Right, that's why it's better.

Alternatively, all one needs to do is determine if it's safe to elevate a process on a UAC prompt before doing so.

This the problem I see in your argument; you assume everyone is an average user who happily clicks away on every UAC prompt they get without actually knowing what they are elevating. Yes, there are many (probably most, sadly) who fall into this category, but that is their problem for not being better educated and exercising better resposibility if they choose to run as admin. There seems to be too much "hand holding" expected from the O/S. Also keep in mind, and this important, not all applications being run under protected admin mode request elevation. The browser, for an important example, does not do this, so it is always running with a reduced token attached to it.

Yep, I agree, for Windows users but I would say this is not true for your average Linux user, who are probably far more responsible than the average Windows user. A linux user uses sudo from their user account to elevate a process.

Makes sense to me.

I guess I have to ask, how is a user who knows the password and insists on running as admin going to benefit through alternative security measures such as those you and kees mention? I can - and have - easily secured the pc's in our household from less knowledgeable family members by denying them the admin pw, so they run as limited or standard users, depending the O/S, and of course employ other means such as Sandboxie, win fw, router, EMET, SRP and AppLocker. This has worked extremely well for years so far, but of course if I give them full admin credentials, I've no doubt infections will occur to one degree or another. I'm not against what you guys are doing, as long as those you've done this for don't have to be dependent upon you all the time if something goes wrong, but it would probably be best, as you've mentioned, if MS were to implement it themselves in a future O/S release.