Hacker News Reader

Comment by dataflow | Hacker News Reader

> Please make sense.

They do make sense. You're missing something critical in the argument.

> So what’s interesting is MS say that UAC isn’t a security boundary. Which is some users to admin.

This is incorrect. UAC is for already-admin users; it's not "some users to admin". The security boundary exists around standard users, not admin users.

This might not be what you like, which I totally get, but it does make sense. If you want a security boundary, don't create a user in the Administrators group.

View on HN

> If you want a security boundary, don't create a user in the Administrators group.

As a user aren't you essentially forced to this to have a usable desktop experience? I mean, sure, there is a boundary.. but it's drawn rather carelessly around the entire stack.

Depends what you're doing?

Using any non Microsoft software.

Like what? Chrome? Firefox? Acrobat? Photoshop?

I’m the only local admin on my mother’s laptop, she’s never noticed and I’ve not logged in to do anything in over 2 years.

Yeah, exactly. It really depends what you're doing. If you're doing software development as part of your job, that's obviously going to require admin privilege way more often than if you're answering emails.

Even doing extensive software development - including WSL, Docker, SQL Server, and other services needing low level access - Admin privileges usually only come up when installing, updating or uninstalling software.

Only problem is that certain things update constantly (VSCode)

> Only problem is that certain things update constantly (VSCode)

Can't you just install it at the user level? https://code.visualstudio.com/docs/setup/windows#_user-setup...

> Can't you just install it at the user level?

Sure, if you want your ordinary non-admin user to have write access to the executables, which makes it a lot easier for some malicious piece of software to hack them since it no longer needs to get root permissions.

If malware is already running as you with the ability to write to your files, what does it gain by Trojaning your VSCode to do bad stuff instead of just doing the bad stuff directly?

Trojaning your VSCode means trojaning the compiler that makes executables for you so what gets compiled is not just the source code you put in. And these are executables you might end up shipping somewhere. Is it really so hard to see why doing that might be something malware would want?

> Sure, if you want your ordinary non-admin user to have write access to the executables, which makes it a lot easier for some malicious piece of software to hack them since it no longer needs to get root permissions.

As if non-admins have no way to create a new executable and run those instead? Windows has a million ways to run code, both visibly and invisibly. Why would malware prefer to trash an executable that the user relies on for daily work and risk revealing its presence so quickly?

Agree, but also you don’t need the entire session running as admin. I usually leave a terminal and IDE running as an admin user with the rest of the session low-priv. Obviously some security weaknesses there but it’s better than having a whole admin session.

I've been using a separate, local admin account and non-admin users for a while for friends and family.

There's not a lot a typical user does that requires admin. For the odd software that breaks Windows' conventions, it's usually enough to install it outside of Program Files.

Of course with the push towards Microsoft accounts for login, this might soon be difficult.

Really threw in a wrench in my day once when I realized guest accounts were disabled years ago, I just wanted to hand a laptop over to a 3 year old to watch paw patrol and to create a new user it was having me go through a Microsoft account flow complete with 3 security questions. I didn't feel any safer afterwards.

> it's usually enough to install it outside of Program Files

Meaning, in a user's home directory somewhere? That's even worse, because now that user has write access to the executables. Which makes it even easier for some nefarious piece of software to pwn those executables, since they don't even need to get root permission.

But the executable can still only run in the context it exists even if it is compromised. This is akin to SELinux...

You cannot compromise an executable run without permission and magically get Administrator or some higher privilege level without another exploit. Sure that specific user's data may be compromised but in the end the system remained secure.

Also keep in mind Microsoft by default has a ton of sandboxes and checks on those applications which will likely get caught as well should that compromised application try to access something it shouldn't.

I don't personally know of a mass security event involving Windows that cannot be chuaked up to failing to implement security updates. Sure Microsoft has some massive security issues but in general their track record isn't as bad as people try to make it out as.

There are enough reasons to hate windows without making up new ones.

> I don't personally know of a mass security event involving Windows that cannot be chuaked up to failing to implement security updates.

The recent global ClownStrike outage?

Not even Microsoft related?

Huh? You specifically said "a mass security event involving Windows". The Clownstrike outage certainly qualifies.

It qualifies about as much as log4j qualified for linux.

If you aren't entirely in the know crowdstrike had a very similar issue a few months before with Redhat distros so was that a Redhat issue?

If you were asking for examples and said "involving Red Hat [Enterprise Linux]" then yes, that would be "involving Red Hat [Enterprise Linux]".

If you meant "caused by", then maybe use that instead of "involving"? ;)

If you purely want to debate semantics then sure. Cause by.

If you want to get fancy you can set permissions on a per-file basis, so only admins have write/modify access to the execuable files.

I'm not that worried about that, as the executable won't get admin privileges without some exploit, so I don't go there. But it's an option.

That used to be the issue in the XP era, and is the reason why the transition is why UAC was so hated. But today you can have a very normal desktop experience without admin permissions.

You have to switch to your admin account for some settings and maybe half the time you are installing new software, but everyday stuff now works well without privileges

And commonly you don't switch to the admin account outside of entering the admin credentials when the UAC is displayed.

There are still too many applications that unnecessarily require admin credentials to do something (I'd love the system to report exactly what the app is trying to do) but it is a lot better than it used to be

I actually like UAC.

Specially when it asks me if I should allow HP printer driver to download new updates. No thanks I'll keep the minimal driver Mr. HP.

For sure, denying unexpected UAC popups is a rather satisfying reflex at this point.

... right until you need to bounce the printer spooler (service) to unwedge your ability to print. (And reboots don't always help — then, it's the only way).

I run my personal desktop as a non-admin user. Every now and then I need to provide creds to my admin account, but the majority of what I do does not require it.

Best way to protect windows at home is actually to have two accounts - one standard you login with and use day to day and another admin account you really never need to login as. Anytime you need to install something or get admin access a pop up asks for your admin account and password.

Basically this is the default way Linux works (not entirely the same but similar enough) with sudo. And the way that every corporate IT department runs windows.

Another advantage is that if some malicious app tries to access something it shouldn't you will immediately know as the admin pop up will trigger.

> this is the default way Linux works (not entirely the same but similar enough) with sudo

Kinda sorta. Here "not entirely the same but similar enough" means "doing the one major thing that Linux does not force you to do", namely, creating a whole separate user account just so that MS can make the braindead claim that a security boundary isn't being crossed when you enter admin permissions from an Administrator account. On a Linux system you only need to create one user account, and put it in the sudoers group, and Linux then properly treats every attempt to do something with sudo as crossing a security boundary and acts accordingly.

Except root is that account. You're still crossing a user-boundary same as Windows. If you give your user CAP_SYS_ADMIN that's like putting them in the Administrators group.

I think you are very confused about what sudo and being in the sudoers group does? sudo is just a command which lets you execute a command as another user. In the typical use case, it lets you execute a command as root rather than as your current user. For it to do anything useful you have to do exactly the same thing as you do on Windows: create a second unprivileged account and log into that instead of root.

> I think you are very confused about what sudo and being in the sudoers group does?

I think you are very confused about what a Linux user actually has to do--and not do.

> create a second unprivileged account and log into that instead of root.

No, you create one account. The root account doesn't have to be created. It's automatically there, built into the system. On Windows, you have to explicitly create two separate accounts, one with Administrator privileges and one without.

> No, you create one account. The root account doesn't have to be created. It's automatically there, built into the system. On Windows, you have to explicitly create two separate accounts, one with Administrator privileges and one without.

Correct, but you're missing the point. There's practically no difference between Linux and Windows when you need to escalate privileges, except having to enter credentials for another (privileged) user than your current (unprivileged) user. The security boundary is there and the user experience is basically the same. Everything else is just nitpicking.

On windows, you just create one then do a "runas TrustedInstaller"

> If you want a security boundary, don't create a user in the Administrators group.

Which makes no sense. The fact that a user is in the Administrators group does not mean every single action they take should automatically have root permissions, or that using the UAC prompt to get root permission for a particular action shouldn't be treated as crossing a security boundary. On my Linux system, the fact that my user is in the sudoers group doesn't mean Linux just throws up its hands and says, oh well, can't enforce any security boundary now for what that user does. MS is simply punting here. But of course Windows was never designed for security, and what braindead security it does offer was bolted on as an afterthought.

> Which makes no sense.

You're twisting what "makes sense" means here. What they're saying makes sense with respect to the current design. They have had a design with one sharp security boundary and maintained it... for decades. Their statement is entirely consistent with that, and in no way nonsensical. You're saying it "doesn't make sense" to mean "I think this is poor design, and there should be multiple layers of security boundaries", and you're obviously welcome to have that opinion, but that doesn't mean their disagreement implies their statement is nonsense.

I fail to see the fundamental difference with Linux you're talking about. Typically adding a user to the sudo/wheel group mean precisely that they can run whatever as the superuser (root). Once you're root, Bob's your uncle.

Sure you can tweak it to only allow certain commands, restrict it to another group, etc. Which would be equivalant to, in Windows, probably using another group(s) than Administrators and assign privilegas as appopriate.

I have a lot of unfavorable opinions of security fundamentals in Windows but you're barking up the wrong tree here.

From your other comment in this thread:

> The issue is not that people don't understand how MS defines what is and is not a security boundary.

With all due respect, check your assumptions...

Reply on news.ycombinator.com