Applications; Portable vs. Installed
-
@jmoore said in Applications; Portable vs. Installed:
@scottalanmiller said in Applications; Portable vs. Installed:
@jmoore said in Applications; Portable vs. Installed:
@scottalanmiller said in Applications; Portable vs. Installed:
Portable apps are not installed. So your users are not installing whatever they want. They aren't installing at all (which generally users don't have the power to do anyway.)
Yeah your right I just phrased it wrong, I know better lol. Just wasn't thinking.
This also means that they aren't "working around" your permissions. The perms that you have in place are only in reference to installation, not in reference to downloading or running. They aren't working around you, it's that the limitations put on the users are far different than believed.
Yes that is correct. I need more coffee. So the idea is to keep users from installing anything on their own unless its an approved app.
That's easy, Windows does that by default. No need to "do anything" because installation is restricted to admins. You only run into the problem if you give end users installation rights.
-
@jmoore said in Applications; Portable vs. Installed:
@scottalanmiller said in Applications; Portable vs. Installed:
@jmoore said in Applications; Portable vs. Installed:
@scottalanmiller said in Applications; Portable vs. Installed:
A big question would be... why do you want to restrict binaries from users?
Thats the sysadmin decision. He considers it a security measure and I can understand it somewhat.
Does he? Because he's not restricting them in any way, and totally okay with all the portable apps delivered in the web browser, right? So he's totally okay with them. Just confused, I'd guess.
Well, I can't presume to know his mind but hes just trying to limit the damage that can be done i suppose. I am guessing that is what he is thinking.
No, he's definitely not. There's no real security factor here. It's a bad habit to agree with someone in a situation like this because it's pretty clear he's just confused or angry and acting like a petulant child. If you can articulate a real concern, great. If not, don't assume that he's acting logically, there's realistically no chance that he is. Both because no one anywhere needs these kinds of restrictions in normal businesses (even Wall St. and hospitals don't do this, maybe a nuclear power station does or military ship) and because he has demonstrated that he has no concept of how applications work by thinking he was restricting "binary execution" when he was actually restricting installation, which is conceptually a different thing.
Installation is important for a lot of reasons to restrict. Binary execution almost never is. Without binary execution, all kinds of things stop working.
-
To think about binary execution, this is an insanely broad category. Everything you run on the computer is covered by this. Including just running a command in CMD or clicking on an icon (which is just running a command on CMD.) So if you restrict binary execution, you end up having to white list every last possible thing that someone could do. Every shortcut, requires a whitelist entry. Every action.
It feels like downloading a portable app and running it is somehow a special case, but it's actually not. MangoLassi is a portable app that runs on JavaScript. So is Facebook, or Google. Every batch file you write is the same thing, just using CMD or PS as an underlying binary. To stop arbitrary execution means that not only do we have to stop the OS from running any binary, but that we also have to stop all platforms on the OS from doing so, as well. So things like CMD, PS, Python, .NET, Java, web browsers, Word, Excel, and on and on... all of which are application platforms that can run their own portable apps, have to be disabled. If we don't then we are simply, arbitrarily taking issue with the language of an app, and not the app itself or the concerns around it.
-
@scottalanmiller said in Applications; Portable vs. Installed:
If you understand it, describe it. What exactly is the concern?
Ok here are some past things that have occurred that are not desirable. These are portable apps.
-
browsers - they do not get updated when I run my chocolatey scripts. users end up using a very old browser and functionality breaks. Some of our department of education stuff breaks quickly if not kept updated and then students do not get financial aid which means they arent spending money with the school.
-
dropbox etc.. - we have strict regulations and can get in lots of trouble if financial or documents with personal information pass to others in this unsecured way. At least the government tells us this is not secure enough for them and the school has to abide by these rules for funding.
-
email - also another regulation is that we have to have a standardized email platform that everything goes through for proper audits. We can't have users using an unknown client to send/receive that cant be monitored. I was told this a long time ago by our financial aid people, so probably another state regulation.
-
rogue apps - a while back we had a user use a "registry cleaner" because computer was running slow. it was actually malware.
-
general updates - this kind of goes back to #1 but anyone running portable apps wont get updated and so wont be secure if it goes on for long enough.
-
-
@jmoore said in Applications; Portable vs. Installed:
browsers - they do not get updated when I run my chocolatey scripts. users end up using a very old browser and functionality breaks. Some of our department of education stuff breaks quickly if not kept updated and then students do not get financial aid which means they arent spending money with the school.
Sure, but that's a concern with all code the user uses. If the user chooses to intentionally not have something work because they didn't use the installed tools, there is nothing you can do about that. They could equally just refuse to do their jobs. Once you have a worker refusing to work, whether they use a broken browser as an excuse or not, this is simply an HR issue of someone not doing their job. This is not related to portable apps.
-
@jmoore said in Applications; Portable vs. Installed:
dropbox etc.. - we have strict regulations and can get in lots of trouble if financial or documents with personal information pass to others in this unsecured way. At least the government tells us this is not secure enough for them and the school has to abide by these rules for funding.
Sure, but they don't need a Dropbox app to do that. If users are going to steal data, you need to fire the thieves when they get caught, and use what security restrictions you can to limit the egress of data. The dropbox app is neither here nor there in this picture because they can just upload through any tool that already exists to the same place.
Again, the portable app here is a red herring. Anything a user can do with a portable app that they download, they can do without it. The functionality of uploading to Dropbox is an issue, the Dropbox app is not. Just like how restricting installation wasn't actually addressing any real issue, this isn't either. For the security here, we'd have to focus on the goal, not get distracted by one limited tool someone might use.
-
@scottalanmiller said in Applications; Portable vs. Installed:
because he has demonstrated that he has no concept of how applications work by thinking he was restricting "binary execution" when he was actually restricting installation, which is conceptually a different thing.
I'm sure he knows the difference, I was just explaining it badly which is on me.
-
@jmoore said in Applications; Portable vs. Installed:
email - also another regulation is that we have to have a standardized email platform that everything goes through for proper audits. We can't have users using an unknown client to send/receive that cant be monitored. I was told this a long time ago by our financial aid people, so probably another state regulation.
Once again, this is a network thing, not related to a portable app. The availability of apps has no means of being a factor here. I guarantee that any requirement like this is being violated by the way that this is stated. No audit requirement will be fulfillable by the end point, it's at the server. So someone here is confused about how email works and is thinking that the tool used to display and compose email is where audits can happen. It is not.
-
@jmoore said in Applications; Portable vs. Installed:
rogue apps - a while back we had a user use a "registry cleaner" because computer was running slow. it was actually malware.
Sure, but if you have any modicum of security, malware has extremely little power. It sounds great to restrict potentially malicious apps, but you can't while still having the computer be generally useful. The power of a user to work, is the power of a user to do damage to at least themselves. You have to choose.
You don't need portable apps for this to be a problem. So much so that almost no one has this as an attack vector. This is very much a 2002 approach. It can still work, but because of modern security it's all but useless. That's why MS Office, email, websites and such are the primary attack vectors now.
-
I understand what your saying. I know ultimately its the fault of the users that decide to do this but its just not how it is handled here and I have no control over that. IT management chooses to do it this way and ask me to enforce it as best I can.
-
@gjacobse said in Applications; Portable vs. Installed:
@jmoore said in Applications; Portable vs. Installed:
@jmoore said in Applications; Portable vs. Installed:
One thing I found about portable apps is occasionally a smarter user will install these. Yeah, it gets around our permissions in Ad because they do not modify the registry. so I do not like them for that reason. I can't have users installing whatever they want.
Something else you can do to make chocolatey easier to install in multiple places is use an xml file with the apps you want for yourself or for departments. I made one for myself but I really don't use it, however I have one for a few different departments here because they some specific things and its hard to remember the install names on each. So I just carry them around on a flash drive.
I'm curious on how you set this up,.. I know I have just been using a simple batch file once the core is installed.
<?xml version="1.0" encoding="utf-8"?> <packages> <package id="googlechrome" /> <package id="firefoxesr" /> <package id="flashplayerplugin" /> <package id="adobereader" /> <package id="jre8" /> <package id="7zip.install" /> <package id="vlc" /> <package id="powershell" /> <package id="silverlight" /> <package id="quicktime" /> <package id="irfanview" /> <package id="treesizefree" /> <package id="windirstat" /> <package id="crystaldiskinfo" /> </packages> </xml>
this file is called staff.config
Then i just use:choco install d:\packages.config –y
-
@jmoore said in Applications; Portable vs. Installed:
general updates - this kind of goes back to #1 but anyone running portable apps wont get updated and so wont be secure if it goes on for long enough.
Nothing makes portable apps not get updates. You don't control them if the end users is the one using them, but they can certainly get updates. And in a typical firm, they probably get more updates, not fewer. But bottom line, it's not IT's concern because it's not part of the managed platform. And it's not something you control.
All of these concerns go back to my "power and control" statement. All of these valid complaints go to the same baseline... HR issues with end users breaking rules, not doing their jobs, or acting badly. None of it is an IT concern or something that can be solved with technology. Why is IT trying to enforce things HR is allowing? Why is one system admin deciding unilaterally that he's in charge of employee's and their jobs and that HR and their managers are not? And if he feels this way, why has he not addressed limiting the ability to run binaries?
-
@scottalanmiller said in Applications; Portable vs. Installed:
Nothing makes portable apps not get updates. You don't control them if the end users is the one using them, but they can certainly get updates.
Oh I know they can get updates. I am just saying they won't because I put chocolatey in my images and I run updates by my script every day. So that is the concern.
-
@jmoore said in Applications; Portable vs. Installed:
I understand what your saying. I know ultimately its the fault of the users that decide to do this but its just not how it is handled here and I have no control over that. IT management chooses to do it this way and ask me to enforce it as best I can.
No, you have no control. But you do have control over how you look at it and present it or talk about it. It's very, very important that you understand that it's hubris and confusion of an impotent admin who is attempting to flex his muscles (and failing) to try to show employees that he's their "master" and they must bow powerlessly before him, while defying HR and management, while also completely misunderstanding computing and failing to in any way do what he set out to do.
When you don't about it, don't say "you understand" because you shouldn't, his desires clearly don't align with the rules, and his actions show that he didn't understand computing basics. He is acting irrationally, from all signs (and history of how they work there), so it is very, very important that you avoid acting like he's rational or making sense. You need to distance yourself from what is just him being on a illogical power trip and present it as "my system admin isn't very competent and in acting emotionally he does X because he doesn't really understand how things work."
There is a huge gap between accepting when a rule affects you and you must follow it, and presenting a rule as something you agree with and understand.
-
@scottalanmiller said in Applications; Portable vs. Installed:
But bottom line, it's not IT's concern because it's not part of the managed platform. And it's not something you control.
yes this is why it is frustrating lol. I am asked to control it as best I can.
-
@jmoore said in Applications; Portable vs. Installed:
and ask me to enforce it as best I can.
Because they don't know how, presumably
-
@scottalanmiller said in Applications; Portable vs. Installed:
HR issues with end users breaking rules, not doing their jobs, or acting badly.
I agree totally but HR does not deal with them properly, if at all. I have never seen repercussions from someone doing these things. Basically we are paid so bad here , they don't get rid of people unless something truly outrageous happens and that is pretty rare. People almost always leave on their on first. We have a high turnover rate.
-
@scottalanmiller said in Applications; Portable vs. Installed:
Why is IT trying to enforce things HR is allowing? Why is one system admin deciding unilaterally that he's in charge of employee's and their jobs and that HR and their managers are not? And if he feels this way, why has he not addressed limiting the ability to run binaries?
Unfortunately I can't answer any of that.
-
@scottalanmiller said in Applications; Portable vs. Installed:
No, you have no control. But you do have control over how you look at it and present it or talk about it. It's very, very important that you understand that it's hubris and confusion of an impotent admin who is attempting to flex his muscles (and failing) to try to show employees that he's their "master" and they must bow powerlessly before him, while defying HR and management, while also completely misunderstanding computing and failing to in any way do what he set out to do.
I get what your saying and am learning how to properly look at things. That is why these discussions are good!
-
@jmoore said in Applications; Portable vs. Installed:
@gjacobse said in Applications; Portable vs. Installed:
@jmoore said in Applications; Portable vs. Installed:
@jmoore said in Applications; Portable vs. Installed:
One thing I found about portable apps is occasionally a smarter user will install these. Yeah, it gets around our permissions in Ad because they do not modify the registry. so I do not like them for that reason. I can't have users installing whatever they want.
Something else you can do to make chocolatey easier to install in multiple places is use an xml file with the apps you want for yourself or for departments. I made one for myself but I really don't use it, however I have one for a few different departments here because they some specific things and its hard to remember the install names on each. So I just carry them around on a flash drive.
I'm curious on how you set this up,.. I know I have just been using a simple batch file once the core is installed.
<?xml version="1.0" encoding="utf-8"?> <packages> <package id="googlechrome" /> <package id="firefoxesr" /> <package id="flashplayerplugin" /> <package id="adobereader" /> <package id="jre8" /> <package id="7zip.install" /> <package id="vlc" /> <package id="powershell" /> <package id="silverlight" /> <package id="quicktime" /> <package id="irfanview" /> <package id="treesizefree" /> <package id="windirstat" /> <package id="crystaldiskinfo" /> </packages> </xml>
this file is called staff.config
Then i just use:choco install d:\packages.config –y
I'll have to give that a try on my next build. neat way to address the install.