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".
-
@Obsolesce said in Re-evaluating Local Administrative User Rights:
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
You are focused on a single kind of threat, not security in general.
My concern is all of it but I don't have time to give an example for every single security issue. If you have more and better ones, please list them. I'm looking for as much as possible here.
Just... all except the one that you keep mentioning. Ransomware is unique in that it is a specific threat that is pretty egregious without admin rights. Essentially nothing else is really like that.
So all traditional threats is what the rest of us are discussion. All virus, trojans, root kits, remote execution tools, etc. All of the things we talked about as an industry before getting distracted by ransomware. All of the things that stuff like antivirus and no-local admin rights are designed to protect against.
-
@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.
-
@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.
-
@scottalanmiller said in Re-evaluating Local Administrative User Rights:
@Obsolesce said in Re-evaluating Local Administrative User Rights:
Software in Win10 doesn't just get admin rights, that requires a very specific set of events or oversights that don't exist in this case. If a random program wants to execute from downloads folder or somewhere similar, it will do so as standard user. So it can't just get admin rights and hide itself.
That "very specific set of events" is just... "the end user clicked the thing that they click constantly because that's what they are trained to do". There is an effective "ok" button and once you are in the mode of clicking that, the "specific set of events" doesn't exist. So once you make end users local admins, it disables that protection in the brains of essentially all end users (and IT pros.)
Yeah I totally get this and is HUGE. I have this noted.
-
@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?
-
@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.
-
@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.
Bloated (considering the size of today's drives) is not something that worries me, or more - but certainly there are some who are worried about this, and with good reason.
But my point is - as the admin, preventing execution of things we haven't provided to our users seems like a great goal.
-
This part of the reason we are seeing more SaaS based solutions, and part of a reason the Online Office discussion was so important. If you are using SaaS based apps and a suite like Office Online or Zoho you basically have very little risk.
Workspaces become disposable and a variety of different, more secure platforms can be introduced like Unix based systems.
-
@Dashrender said in Re-evaluating Local Administrative User Rights:
You CAN get rid of all of those things mentioned in locally install apps as well.
Sure, but local installed apps just have more to break.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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.
hmm.. interesting.
I have a powershell script that 80% of my users have to use to change printers between locations. I suppose I could compile it into an EXE and whitelist that.
-
@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.
-
I have not read the whole thread, so I apologize if I missed something. I read through the first ~20 posts and decided to toss my stuff in here.
We currently use a tool called CyberArk for privilege escalation. It requires that an exe be registered with it by an admin, but allows an end user to silently escalate a process that has been so registered. This gives us the ability to remove admin rights from almost everyone (I don't have any), and still allow the function that is needed for business operations. Depending on your scale it might not make financial sense, but it saved my city a large chunk of time and resources.
-
@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.
-
@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.
-
@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.
you mean the end user can't - yeah, that's not a risk in my environment. But I can see how that would be in your MSP.
