Re-evaluating Local Administrative User Rights
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
What I'm getting at, is if the device is actually REALLY any bit safer without the user having local administrative access? I mean, if someone external wants in to a device, is the assigned user not having local administrative access making the device any more secure?
The concern isn't necessarily about downloading a piece of malware.
Those two things are one and the same. If someone wants remote access, then getting the end user to accidentally download malware is the number one way to achieve it. You can't separate the two concepts.
And in those cases that's what the AV is designed for, especially Trojans. But that's not my point here, my point is in those cases it's about trickery via social engineering and/or web links to steal credentials to services. Not particularly about the users device.
No, AV is designed for viruses. Trojans bypass AV by their nature.
My point is that trickery IS what not having local admin rights is all about.
I see, and good point. AV in my experience has prevented soo much Trojans though. So I am not sure what you mean that AV doesn't stop Trojan infected software, because I've seen a lot of live logs where it does.
It must stop some, but I pretty much never see if. If an end user downloads something and tries to execute it with local admin rights, it's going to run, AV or not. In the cases where you've seen it stopped by the AV, was it attempted to be run by a local admin?
No, on Windows, most AV / Anti-Malware is real-time monitoring of file changes. I don't remember what it's called but it almost is nonexistent in Linux. As soon as it's downloaded, if it's even allowed to, it's gone. If that fails, then upon clicking on it or browsing the directory it's located in triggers the AV to get rid of it. User admin privileges are irrelevant there.
Heuristic Scanning
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@IRJ said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Dashrender said in Re-evaluating Local Administrative User Rights:
As for software/viruii that don't require local admin rights, uhuhm - CHROME, rights levels don't matter.
Huh? Chrome isn't a thread because of this.... no admin access whatsoever.
This was an example of software that could be run in user space with zero local admin rights - nothing more. The remainder of that post (or a followup one) pointed out that I don't want to see users able able to execute an executable that wasn't installed by an admin - but I'm not sure that's possible, or really reasonable.
Yes, but it's "run in the user space". Everything works that way. Office suites, you name it. Chrome is just a "portable app".
Yeah, I just don't like the idea of portable apps - as an admin, I'd like to prevent them. Because there is no reason in most businesses that a user would need to run a portable app. If you prevent execution from any user rightable space, you can kill so much of this malware.
That's not a good way to think of it. You should never dislike portable apps, all that means is that they don't require admin privs or need to be installed to run. Installing just means putting it into the system database.
Portable apps have loads and loads of reasons to exist. They are more stable, easier to maintain, avoid DLL hell, etc. They don't link to system resources and so are more resilient to all kinds of problems and tend to work across more OS versions.
Portable apps tend to be bloated, that's pretty much their only negative.
Execution allowances is totally different. Not allowing end users to make or acquire their own tools and run with their own privs is very different than disliking the avoidance of system dependencies in an executable.
You CAN get rid of all of those things mentioned in locally install apps as well.
There is only negatives to locally install apps IMO. Some would argue that it is required for speed, but in reality a properly built SaaS app does not have issues.
He's not intending to argue the "locally" part, but the "installed" part. The context was installed vs portable apps, both local in this case.
I guess what I want is a white list of allowed executable - I don't care if they are portable or not, I care that users shouldn't be able to execute them unless allowed by IT.
Right, that makes sense. DLL linking or database inclusion doesn't really. Portable doesn't imply any additional access from the users.
Just be aware that while listing means no OS level scripting from end users, even of their own making. But that's not necessarily bad.
Scripts shouldn't run unless they are signed and the cert is allowed. That's how we control that.
The problem is... you can't write your own.
Maybe I'm missing your point. So they can't run Vscode and write a script? Or notepad?
They can't write a script, at all. In any way. If only whitelisted things can run, you can't make any of your own automation.
Write or run?
Well they can write it, but that's it.
-
What are potential underlying issues and fixes that you all may have ran into, causing the perceived requirement of local admin privileges?
Quick easy example to make the question clear:
Issue:
- A certain app some people use requires local admin privileges to install.
Fix:
- Make the app available to install via the "Company Portal" or other self-service software install portals.
-
Another point:
Timed or temporary local admin privileges? Do you feel that is at all any more or less "secure"?
-
What's the advantage of giving users admin rights?
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
Another point:
Timed or temporary local admin privileges? Do you feel that is at all any more or less "secure"?
How is it controlled?
For me of course it's still more secure than simply giving the users local admin all the time. But really, why do they need it at all? Is IT so backed up that they can't get to a user request to install an approved something for the user? How often are users needing to install things that they need this access?
I mean, if they are a tester for the company - perhaps they should have a VM that has no access to network resources, say, just internet, and the user had full control over that.. just one idea.
-
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
This is still under evaluation, as well as evaluating all of the causes or perceived needs for local admin privileges in the first place. As of now, we do not allow any local admins at all (exceptions exists, as well as timed local admin privileges (similar to sudo I suppose in the "timed" way)), so currently, not an issue, but could be better.
This post is about being proactive on the topic, as I have direct influence over some decisions. So I'm gathering as much as possible from as many angles as possible.
I said from the very beginning (not here) that I'm not on board with it and gave quite a few of the reasons we all mentioned here, some of which that were met with a few anecdotal counters.
So, this is my change to gather as much as possible, showing all the points. This is why I'm trying to counter everyone's input, so that I can better prepare for the anecdotal counters thrown my way later.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
This is still under evaluation, as well as evaluating all of the causes or perceived needs for local admin privileges in the first place. As of now, we do not allow any local admins at all (exceptions exists, as well as timed local admin privileges (similar to sudo I suppose in the "timed" way)), so currently, not an issue, but could be better.
This post is about being proactive on the topic, as I have direct influence over some decisions. So I'm gathering as much as possible from as many angles as possible.
I said from the very beginning (not here) that I'm not on board with it and gave quite a few of the reasons we all mentioned here, some of which that were met with a few anecdotal counters.
So, this is my change to gather as much as possible, showing all the points. This is why I'm trying to counter everyone's input, so that I can better prepare for the anecdotal counters thrown my way later.
There has to be advantages to make it an actual consideration, correct?
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
Another point:
Timed or temporary local admin privileges? Do you feel that is at all any more or less "secure"?
Better, but seems like too much effort.
-
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
Bypassing formal IT for basic requests and customizations, and not needing or wanting to put in an automated system to handle those requests.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
Bypassing formal IT for basic requests and customizations, and not needing or wanting to put in an automated system to handle those requests.
Apparently that's not been an issue in another location for another company. However, I'd have to argue, how would you know?
-
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
Some applications are really tough to get working without it, and many lose support if you take it away. No legit app, of course, but the bulk of businesses run totally ridiculous applications.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
Some applications are really tough to get working without it, and many lose support if you take it away. No legit app, of course, but the bulk of businesses run totally ridiculous applications.
I believe I have heard this may be one of the issues, for some people... however, I'm still not on board for a blanket enablement because of a fringe app or two for less than 0.05% users.
Edit: But again, still evaluating that.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
How is it controlled?
In a way that works 100% well.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@IRJ said in Re-evaluating Local Administrative User Rights:
What's the advantage of giving users admin rights?
Some applications are really tough to get working without it, and many lose support if you take it away. No legit app, of course, but the bulk of businesses run totally ridiculous applications.
I believe I have heard this may be one of the issues, for some people... however, I'm still not on board for a blanket enablement because of a fringe app or two for less than 0.05% users.
Edit: But again, still evaluating that.
Agreed, just one of the reasons that people state.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
It seems like restricting users to non-admin privileges causes more inconvenience and service desk overhead than it's actually worth.
It absolutely causes more issues when users have local admin rights. I dealt with this crap daily until I finally got buy in from clients across the board to remove admin rights.
If you have a user that needs a local admin right to perform any daily task, the problem is the software being used. Not the user or IT policy.
-
@JaredBusch said in Re-evaluating Local Administrative User Rights:
If you have a user that needs a local admin right to perform any daily task, the problem is the software being used. Not the user or IT policy.
This is the hardest part to tackle. But it's worth tackling. It's amazing how easily this can often be fixed.
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
And, from a security perspective, doens't really seem like any more of a factor one way over the other.
Of course it is more of a security factor. While, sure most shit can run in local user space, and mess up the user profile, it is restricted to the user profile. Sure the odd 0-day that executes easily will ignore that, but most 0-day have tricks to make them most effective.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@JaredBusch said in Re-evaluating Local Administrative User Rights:
If you have a user that needs a local admin right to perform any daily task, the problem is the software being used. Not the user or IT policy.
This is the hardest part to tackle. But it's worth tackling. It's amazing how easily this can often be fixed.
It is simple enough to fix with a unique account that has local admin rights and then a
batfile calling a/runas /savecreds. I have a number of old service applications that require this at one client. The first time you use the/runas /savecreds, IT staff can enter the password and then the Windows Credential manager will keep it and the user can just click the icon afterwards.Sure a malicious user will be able to figure out what is happening and exploit that, but that is not an IT problem. That is a HR problem.
-
What about cases where a computer is used for dev work on which the users are using mob programming practices and running docker containers?
What are some ideas in that space?
