Disabling UAC Because It Doesn't Provide Real Security

Software & Operating Systems Windows
1

The context of the original post is the following posted earlier:

In other words by following the above outlined installation workflow, a lot of common windows problems can be solved, like missing library errors.

It should be obvious why UAC should be disabled for the initial system setup, especially given that the initial setup tends to be done in an administrator level account which subsequently requires numerous deliberately-administrative changes to the system. Being prompted every few seconds to install 10+ libraries, dozens of programs etc is not productive and UAC actually pauses many installers for an extended period lengthening the time initial setup takes unnecessarily, and pointlessly.

But what about after initial setup? Should UAC should be left disabled or get enabled again? Does it cause more “small windows problems” or does it create them? If the security benefits of UAC are worth it, then despite any small programs it creates, then it can be worth it in some environments.

Read the discussion before posting. Context is important you know? The false sense of “security” that UAC provides was discussed in detail above with both reputable sources and examples of how to bypass it provided. Using UAC while logged on in an administrative account is especially pointless, only creating lots of small windows problems, while having -zero- positive impact on os or user data security.

UAC can makes sense to enable to use the “run-as” functionality of it when combined with a standard user account for day-to-day operations, granted that doing so will continue to cause UAC related small windows problems. If the user understands the myriad of small windows issues caused by leaving UAC enabled, then then this configuration is not too bad, depending on the user.

As a security conscious user, I would rather use thick VMs with UAC disabled since doing so mitigates most small windows problems while also isolating malicious software (including randomware) from user data. Considering that VMs are disposable and clonable by design, leaving UAC enabled in them is also fairly pointless. VMs provide real security, not the fake isolation that UAC in AAM provides.

In other words, saying it should always be enabled only causes lots of small windows problems pointlessly and does not adequately take into account the context that the user disables UAC in. That is what I have been responding to. The user should dictate how to configure and run their system, not an OS non-feature, nor ideology.

If you want to drop the topic then stop prompting me for a reply about it.

2

But why?

Day to day use you shouldn’t see it. If you’re continually getting UAC prompts, there’s something wrong and you should probably see what’s constantly requiring elevation and fix it rather than sweeping the issue under the rug :smiley:

edit:
Also, top windows security tip: don’t log in with an administrative account. For stuff that needs admin, use “run as” explicitly to do so.

3 Likes
3

There are no security benefits to UAC under typical use and UAC breaks most applications that require any sort of access to anything. Most of the things I do require some sort of administrative access.

For example, UAC breaks notepad by blocking writes to C:\file.txt. Why do I need file.txt to be in C:? Because that is the location where I have decided to use.

Another (early) example is renaming an entry in the start menu. Of course they fixed the renaming anything causing UAC prompts every-single-time by making it auto-remember that it was elevated before which leaves open the possibility for malicious software to hook that for admin rights without elevation. Great.

A more recent example is that Steam’s voice chat does not work with UAC since push-to-talk requires intercepting the keyboard press while another application is active. Voice chat with friends? Who needs that.

UAC cannot even prevent ransomware from encrypting everything. What users really care about is their data, not the OS. The OS is easily replaceable.

UAC is explicitly not a not a security feature, nor was it engineered to be.

It’s important to be aware that UAC elevations are conveniences and not security boundaries. A security boundary requires that security policy dictates what can pass through the boundary. […]
Because elevations aren’t security boundaries, there’s no guarantee that malware running on a system with standard user rights can’t compromise an elevated process to gain administrative rights.

Elevated AAM [admin approval mode] processes are especially susceptible to compromise because they run in the same user account as the AAM user’s standard-rights processes and share the user’s profile. Many applications read settings and load extensions registered in a user’s profile, offering opportunities for malware to elevate. For example, the common control dialogs load Shell extensions configured in a user’s registry key (under HKEY_CURRENT_USER), so malware can add itself as an extension to load into any elevated process that uses those dialogs.

-Mark Russinovich on Windows Vista User Account Control
https://web.archive.org/web/20140402171410/http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

In other words, if using an admin account with UAC is pointless. It needs to be standard + UAC to have any security benefit at all, which means no admin software at all or getting prompted every 1/2 second. That or having the OS remember the elevations and being susceptible to malware hooking. gg UAC

UAC was deliberately designed as a user annoyance “feature” back when applications were doing a lot of unsafe things (not even DEP compatible for example) in the WinXP days and using admin features when they did not really need to be. It was designed to encourage application developers to write their code in a more friendly by having the OS annoy users that their software was not written in a way compatible with normal user access. “Use our software. It will not make the OS annoy you.” That is what MS wanted app devs to advertise going forward.

I would say the OS’s job is to help the user do what they want, like say work productively by running the programs they need to do day-to-day work. UAC interferes with that process, examples above, while doing nothing to enhance the OS’s security.

For that reason, I consider disabling it a necessity for anyone using an admin account at all. I suppose I could do a standard account + UAC but why? It is the job of my OS to run my software and manage my files. It is not my job to cater to the whims of the OS trying to deliberately annoy me.

1 Like
4

Yet i have an entire enterprise of users running without admin access on their machines…

So basically… doing it wrong… documents aren’t supposed to live in c: root. You don’t store your own files in / on a unix box either.

This is what i suggest.

Do not log in with an administrator account
Use run-as when required, or prompted by UAC.

7 Likes
5

Work computers are typically more locked down than personal computers so the two are not really comparable.

Maybe you don’t store files on C:, but maybe I do. That is the issue. UAC is telling the user to run how to run their systems. It does not enable/empower users, but instead deliberately causes plenty of issues.

Basically, UAC does not benefit the user. It is not meant to, regardless of marketing details. It is a way of Microsoft to talk to application developers.

Therefore, speaking as a user, there are literally zero benefits to using it.

1 Like
6

I don’t think you understand how separation of privileges works and what UAC is doing in that regard.

Also if you absolutely HAVE to write to C:\ for any reason I can’t even imagine, you can set up the permissions to allow it. You just need to give the user account write access there.

5 Likes
7

If you’re running into a UAC prompt in day to day office tasks then your administrator is not very good at his job.

There are clear security benefits to UAC prompts.

4 Likes
8

The fundamental point I am making is that there is no reason not to write to/execute from C:\ if it is the user’s decision, which should be honored above all else.

There is literally zero-none-nada benefit to using UAC and/or limited permissions on a personal computer because what is valuable is the user’s data, not the OS, which neither limited permissions nor UAC can protect.

Managed systems are obviously different, since there the user’s data is worthless (their resposibility) and you are trying to protect the computers from the users. Domains w/Limited accounts go a long way there.

-Mark Russinovich on Windows Vista User Account Control, link provided above

UAC offers no security benefits to the OS on personal systems by design. Is trivial for malware to bypass via hooking previously elevated applications and breaks many applications or useful features of applications.

9

Using vistas implementation of UAC is a terrible example. It absolutely does offer security benefits to personal systems as it adds a layer to the system. Of course there are ways around it but thats not really the point. Any single layer of security on its own is often not actually great at protecting you. Its many layers together.

The point is, you should avoid turning it off and instead look to see how to set the appropriate permissions and elevate only what you need to elevate in the same way that on linux you should avoid running as root and only elevate what you need.

I think your point that there is no reason not to write or execute on C:\ is also flawed. Theres typically nothing in the root directory that you need to save or execute. Thats exclusively done in sub folders where permissions are granted. The average user has no need to edit anything in the root of the drive, but theres also nothing stopping you from adding this permission either.

At this point I think we’re beyond a small windows problem thread so if you’d like to discuss further perhaps we can make a thread about it?

5 Likes
10

If you want to that is fine, but I have more or less said what I wanted to say in response to the original prompt by thro regarding the fiction that UAC offers security benefits.

The disagreement about whether or not it is okay to write to C:, including / on Linux systems, is probably the core of further disagreement, but is also a different topic.

11

Fair enough

12

UAC allows windows to elevate if required when you are not logged in as an administrator.

Without UAC, you won’t get prompted for credentials automatically (unless they changed this recently, this was tied to UAC since its inception - XP, 2000 and previous would just fail and not prompt if credentials were not sufficient - Vista+ give you an elevation prompt via UAC).

That’s the benefit UAC provides, not some catch-all for an end user being logged in as an administrator tripping themselves up.

So, like i said. Both:

  • don’t log in with an administrative account
  • use shift-right-click run-as or respond to the UAC prompts for admin credentials as required.

So, unless you plan staying logged in as an administrator constantly (dumb), turning UAC off just breaks elevation-prompt-when-required.

13

Do not tell me how to use my computer. That is the core issue here, and why UAC is fatally flawed from a user’s perspective.

The user should dictate their use of a computer system in such a manner that is appropriate to their needs and technical skill level. Only the user can decide that, not the OS, not any program, not any other user.

The operating system and programs should not dictate to the user what they should/shouldn’t do, and limit themselves to suggestions. UAC is a good feature, but from a user’s perspective, is one that is better off disabled because it provides no security benefits, does not protect what users care about and in most circumstances interferes with their basic use of a computer system.

No doubt some users will disagree because they can find reasons that make UAC appropriate to use in their environment, and that’s fine. They can leave it enabled.

However, Do not tell me how to use my computer.

14

Then do so. Noone is forcing you to anything. Setup the permissions properly and stop whining about it. You don’t HAVE to use UAC if that’s what you want.
But the statement that UAC does not have any benefits is not just wrong and misleading, but plain bullshit.

And also, can we drop this topic? It’s not leading anywhere because “some people” have their opinions and won’t budge either way. Not to mention this is a support thread for small issues and not a topic to talk about random BS.

/rant

10 Likes
15

You need to take a chill pill and be humble when offering your opinions about something.

I have never disabled UAC, never had any issue with it and sometimes it even saved me from accidentally executing exes I unintentionally clicked on. This is my experience but I’m not shouting it like it’s God’s truth.

1 Like
16

I thought the whole point of posting a forum topic was being receptive to another opinion - potentially from a person who knew better than you.

We feel your frustration and understand you want to exercise autonomy in how you want to do things but some practices are just better than others. If you really needed a file.txt on the C:\ why not just put a shortcut in it with the file in another location?

2 Likes
17

I like how links regarding the implementation of UAC circa 2007 are used to support the argument that UAC is broken and of no use (when logged in as an administrator), when the whole point is that it provides an elevation method when you aren’t logged in as an admin.

:slight_smile:

edit:

Also, the Aussie DSD (defense signals directorate, basically the guys who recommend methods for securing government high value assets) suggest exactly what i describe, for Windows 10:

  • Turn on UAC
  • require authentication (e.g., elevate to an administrative account, not your regular account)

ref:

https://www.cyber.gov.au/publications/hardening-microsoft-windows-10-version-1709-workstations

I’ll take their recommendations over some guy on the internet referencing shit posted on Mark Russinovich’s blog from 2007. Regarding VISTA.

edit:
Actually, the OPs link is from 2007, the web-archive link is from 2014, when the info was at that point 7 years old. It’s now 13 years old. And yes, i remember reading that same article, back when Vista was current (as I/we were trialing Vista for company roll out at the time, ended up waiting until 7 to get off XP).

1 Like
18

This?

I view it like adding Sudo to a destructive command.
It gives a pause, where the user can consider whether they actually want to do what they did.
But without needing an actual password, because they would just disable
(like when it started)

Because of the low friction/barrier to entry, they spread it’s use wider than perhaps necessary, but all it takes is a click, and it can be turned off if it’s too much on an embuggerance.

19

Just be aware, that if your account has administrative credentials, there are (or were) methods to circumvent UAC prompts (basically exploiting an app that UAC has whitelisted to run without elevation prompt).

However, if you use UAC as I describe above (log in as non-admin, and elevate with an admin account when prompted) UAC is pretty much exactly like sudo.

20

I guess.

I presumed that if you had admin, you could disable it anyway?

At work they don’t let commoners like me do anything that requires the prompt, but it really seems there are less prompting actions.
I don’t know if that is because win10 I have at home if different to win7 at work, or if they set certain actions through policy