Why do idiots disable UAC & claim it's not a security function?

Agree, but they want to be admin. My trick for click happy people (relatives & friends): An admin account with a decent freebie AntiVirus and UAC set to auto elevate (while UAC still on) PLUS deny elevation of UNsigned programs. Move the Documents (User Folders) to a data partition and add a ACL deny "Traverse Folder/Execute" (for drive by protection).

Don't forget to replace the Windows log-on screen with an identical copy carrying the text "Home Premium Special Secured Windows 7" in a well visible font size. This approach will safe you heaps of time

Yes they can't install unsigned programs, but hey when you own a Apple you can only install official Apple signed programs, on your Android smartphone you can install from the AppMarket. So people get used to these restrictions.

 

It does make sense to do as Kees suggests and tie your UAC approval in with your execution/policy control. That way there is only one point of user interaction.

Kees, you'd want some exception under that setup though wouldn't you? eg you don't want browser/doc viewer/media player to be auto-elevated.

 

True, therefore I install Chromium (is unsigned can't auto elevate). For e-mail reader, media player I use run as invoker (virtualises file/registry access as pseudo admin containment) and EMET.

 

The reason running full-time as an admin for ANY user (experienced or otherwise) is inherently bad for security is because it puts all of your other security layers at risk. Consider anti-virus...it runs with admin privileges in hopes of having a leg up on any malware that installs...but now you're allowing any drive-by that installs (which can install regardless of user expertise) to also automatically get admin rights, therefore, it is fighting with the AV at the same level and it will likely win.

So in other words, when you run as an admin full-time, it's not a matter of taking responsibility for your actions, or rather, having the expertise to know how to avoid something. Rather, it's kicking your other security layers off the high ground and forcing them to fight down below at the same level as the baddies.

The only full-time admin setup I personally approve is when it is implemented with full-time sandboxing of web browser and other high risk internet facing apps. Otherwise, I highly advise against the full-time admin approach to security, because it's not much of an approach at all.

Any serious security expert I've seen agrees that Least User Access (LUA) is the first ingredient to any security setup worth its salt...in fact, it's not even the first ingredient...it's the pots and pans that which will cook all other ingredients.

 

By using a standard user account i suppose that one is protecting Windows from all malware that need admin. privileges to run... and that seems to me to be a excellent starting point (some time ago i used a SUA with UAC at max, and configured not to prompt (thanks to m00nbl00d tip), and i believe thats better, from a security perspective, than giving admin privileges to everything i click...)

 

In all fairness, Sully did mention the following...

Although, I'm not sure what he means with not letting the security policy do its thing. Whatever he restricts, and regardless of how it's restricted, it's a security policy... I think.

I'd actually separate different tasks to different SUA/LUAs. Then, I'd either extract the contents of the applications, and see if they can be made "portable", and place them at the user profile folder instead of Program Files, or install them to other user profile location than Program Files, then either apply a medium/low integrity level to whatever it needs, deny execution, depending on how restricted I want it to be, or the permissions it needs.

This way, you can have as many as possible dangerous apps running with low integrity level, without compromising the security of one user account - if you were to use just one account.

By design, one LUA cannot interfere with another LUA.

 

First, lets declare that "we" are simply discussing different viewpoints and opinions. I enjoy learning how others look at things, as maybe there is something of value in how others see things. My way is not the "right" way, just another way.

Now, I understand your overall philosophy, and I would agree with much of it, especially for the average user. However, what I don't really agree with is how you give a blanket statement for everything.

For example, you mention the AV. That technology, to me, is only a last ditch attempt to protect the system. It is always playing catchup to the virii of the day. It can be useful, but hardly what I would call upon for protection for my system. In fact, I haven't used one in years now. I don't think just because I look at it like this everyone should stop using them. They do serve a purpose after all, just not as well as the manufacturers would like one to think - for current virii. For older, known virii, I think they do a fine job. For current virii, I just don't trust them. Seen way too many infected machines with current AV installed.

Now, you mention the LUA is the baseline for good security. I agree, for someone who does not need root 80% of the time they use a computer. But for those who do so many things that need root, I also don't buy into your viewpoint that they still need LUA. Indulge me for a moment...

I believe that if one understands the points of entry for problems (virii/malware/etc), then one only needs to control those points. All other points without entry, why spend extraneous energy on them?

Do tell then, if my browser is started with the rights of a user, how is a process it spawns going to achieve privelage escelation?

Do tell, if the download directory where the browser is told to download to uses a Low IL and has the NoExecute flag set on its DACL, how is a process spawned there going to achieve privelage escelation?

These are just two simple ways to use OS tools to contrain an entry point. Consider then shoring up these constraints with 3rd party tools.

Do tell, how does a browser process, at user rights, forced into a sandbox that allows only specific process to run, escape the sandbox and then also escelate privelages once out of the sandbox?

I fail to see how constraining, in this case the browser, is going to fail. It does not involve the login needing to be LUA, only the process. Granted, it does take knowledge to understand just where your entry points are and just how to constrain them. But, once constrained to a lower token level or applying DACL restrictions, the entry point is controlled.

Should everyone do this? No. Does it work? Yes. Is it fool-proof? No, but then neither is LUA or UAC. The very bottom line is, if you run something with root, it will do whatever it is designed to do. If you don't know what it will do, then you take a chance, whether you are admin or user. I opt to develop a strict way of doing things the severely minimizes the chances of something I don't trust running with root. You opt to let the OS methods do the same thing. And the difference is what then exactly?

Sul.

 

Mis-construed my point

I must know how to restrict it (whatever IT is) and have a means to (whatever that might be), instead of relying on user credentials (LUA/SUA aka member of user group) and thier associated rights and the security policy (those rights, defined within the security policy, for the users group, thus the logged in user), or UAC (assuming a dual token setup, where running with root is easy to do via the UAC popup).

Not that I do things apart from the secpol, but that the secpol is not limiting me as an admin, thus not really effecting me.

Sul.