Hacker News Reader

Comment by tester756 | Hacker News Reader

Initially I thought ur concern is crazy as hell, because who would implement it in such a painful way?

But then I read

>When elevating a process from the command-line with sudo, a UAC dialog will appear asking the user to confirm the elevation:

LOL

But it seems like there are other ways to use it without this dialog

>In this configuration, sudo.exe will launch a new elevated console window and run the command in that window. The new window will be launched with the same working directory as the current window. The new window will also be launched with the same environment variables as the current window. This configuration has a similar flow to the runas command.

View on HN

There's no way that second use case doesn't show a UAC prompt.

The whole point of the split token / UAC elevation is to avoid elevation without user interaction. Imagine malware stuck as standard user just running itself like:

cmd.exe /c sudo malware.exe

Having the sudo command open an entirely separate terminal as an admin user is absolutely ridiculous and completely on brand for Microsoft.

Along with the UAC dialog, I can't think of a worse way for sudo to behave.

What's wrong with entering your password for sudo? How is UAC more secure than a password?

Opening another terminal is one thing this new sudo can do. It's also possible to configure it to run the sudo'd command inline in the current window (mentioned in the linked blog post); there are security tradeoffs to consider.

If you’re running as local admin you just get the dialog, but you’re not using a local admin as your daily driver user acct, right? ..Right? :)

If you’re logged in as a standard user, UAC prompts you for new username and password to authenticate and authorize the privileged operation.

Seems like a horribly convoluted way to manage permissions. Also I have never heard anyone suggest you shouldn't use a local admin account. That's the exact problem UAC was meant to solve.

Having used an unprivileged Windows account, all I can say is no thanks. It's a huge burden if you do anything even slightly more complex than Facebook and email.

As a blanket policy at work, all programmers are admins, everyone else is not. Except when someone is doing a task that requires elevation every five minutes. I'm the only admin on site and it's an unbelievable waste of my time to sit next to someone so I can put in my password every time they click a box. We make those users admins because there's simply no other way to manage it.

Nobody does what you describe. When someone has a genuine need for local admin access, they are given two accounts - an unprivileged account to log in with, and a privileged account to enter into UAC when needed. It would indeed be an unbelievable waste of time to make your IT staff sit next to users to enter admin credentials, which is why nobody does it.

And for the record, "don't log in with a local admin account" is a very commonly recommended best practice for Windows environments. It's unusual that you've never encountered it.

"Nobody does what you describe" is a very... broad statement. I can tell you that "all devs are local admins" is indeed a very popular policy, and has been the case everywhere I worked in the past, oh, 20 years or so - including Microsoft itself.

Another one is local admin account is only temporarily assigned via tickets, with tracking tools every time one needs to log in as admin.

And on UNIX, I have worked plenty of times where no one gets root on the shared development servers, other than IT folks themselves.

> Nobody does what you describe.

Counterpoint: I've never heard anyone do what you describe. Therefore no one does it, even though you've just described to me who does.

What exactly is the threat in using a local admin account? I can't think of anything you could do that wouldn't show a UAC prompt. The entire point and purpose of UAC was to prevent malicious elevation without the user's knowledge. I'm really not sure what you accomplish by adding a password to UAC prompt the user wouldn't have read either way. The end result is the same.

Additional work for IT when people screw up their machine.

I have worked in companies where local admin accounts would be given temporarily for like one hour, after submitting a ticket with a reason.

This was partially automated via a desktop application.

> Also I have never heard anyone suggest you shouldn't use a local admin account.

Only every security audit under the sun. If you work for a sufficiently large organization subject to industrial or governmental regulation, or even carry particular insurance policies, third party audits will flag these practices as liabilities, because its boilerplate recommendation for how a managed windows environment is deployed.

You may work for a large organization where you get local windows admin. Exceptions can be made if a good story can be told about compensating systemic and detective controls that sufficiently mitigate the risk.

However I promise you that someone in that organization closer to security strategy and compliance gets grief over the posture at least annually. Those people shelter you from worrying more about it.

A terminal password prompt can be intercepted by a keylogger and similar things.

UAC is safe from that.

UAC is less secure than a password right?

Reply on news.ycombinator.com