4 ms·
I agree with much of what you say but I wanted to clarify one point. > 3. I like UAC. The article claims that giving users a dialog box to permit admin access
by ChrisSD 7y ago
I agree with much of what you say but I wanted to clarify one point.
> 3. I like UAC. The article claims that giving users a dialog box to permit admin access is good for malware, but the alternative is taking admin away from users altogether on their own computers. I don't think this is an acceptable tradeoff.
The UAC is about persuading legitimate developers to do the right thing. In that respect it has been successful. Many developers have learned they should not be annoying users with the admin dialog unless they really do need enhanced privileges.
The UAC has no other benefit. It's not a security barrier (malware can bypass it, or get the user to). If you're running on an admin account you are admin and all win32 programs running on your desktop have admin rights. They just need an elevated token to make use of them which, as I said, is easy enough to gain. The exception is if programs create their own sandbox to run sub-processes with limited rights.
UWP is an attempt to sandbox applications by default and thus allow the user to be admin without programs being admin by default. However its uptake has been slow.
In short, it's not the UAC that's the issue. It's Windows permission model. Microsoft is aware of this and is attempting change.
- brianpgordon 7y agoI've always been skeptical of the Windows security model as a user but I didn't think it was that porous. Thanks for setting me straight. I found these articles explaining why it's so bad: https://tyranidslair.blogspot.com/2017/05/reading-your-way-around-uac-part-1.html https://tyranidslair.blogspot.com/2017/05/reading-your-way-a... https://tyranidslair.blogspot.com/2017/05/reading-your-way-around-uac-part-2.html https://tyranidslair.blogspot.com/2017/05/reading-your-way-a... https://tyranidslair.blogspot.com/2017/05/reading-your-way-around-uac-part-3.html https://tyranidslair.blogspot.com/2017/05/reading-your-way-a...
- ChrisSD 7y agoFor enhanced security you can run as a "standard user" then switch users whenever you need to run something with admin privileges. And by switch users I mean literally go through the login screen to change desktop to an admin user. Obviously this isn't ideal. I've been using this set up for awhile and mostly I can live with it but installing/updating programs is a pain. Especially if they bizarrely don't expect to be installed from a different account then the one that runs them (games can be particularly bad about this, even modern ones). Of course there's a lot a malicious application can do even with standard user privileges (e.g. it has access to all your files and the internet). It's easier to get rid of though.
- freeAgent 7y agoYou don't have to switch to an admin user account. You can provide admin credentials when needed or right click an installer and run as admin manually (and provide the credentials then).
- ChrisSD 7y agoNo. That causes a process with admin rights to run in the context of your desktop session. This is exploitable by non-admin processes running in the same session. The inter-process security in Windows is unfortunately weak when they share a desktop session.
- freeAgent 7y agoYou're assuming at that point that you're already compromised or running malware, though. If you aren't already infected with malware, this is not a problem. If the installer itself is malware, then switching to an admin account to install it obviously offers no protection.
- anchpop 7y ago> It's not a security barrier (malware can bypass it, or get the user to) All it needs is the user to have one of many buggy programs installed on their computer, for example Steam. If you're doubtful of this, replace the steamservice.exe executable with one of the same name that does whatever you want (doesn't require a admin privs and can be done by any user on the machine) and then reboot - it will run as admin with no prompt. Source: https://nvd.nist.gov/vuln/detail/CVE-2015-7985 https://nvd.nist.gov/vuln/detail/CVE-2015-7985