Show Evidence Standard Users are unable to Install Applications

[janderson215]

Hi, I have a technical question on locating a particular setting that we are looking to show evidence of in our JSS configuration.

Our fleet requires an Admin account to install applications on all of our endpoints. This is a setting that we want to keep, but I cannot find where to show evidence of this. The official Apple documentation shows Standard Users are able to install applications, so it seems this is not an inherent limitation of a standard user account. I also do not show this setting is enabled anywhere in our Configuration Profiles. Where else could this restriction be?

Thank you,

Jon

[npynenberg]

Most installers by default want to write an application to the standard Application directory, which does require an administrative password UNLESS you install them through Self Service.

SOME installers do permit the user to install applications to an Applications directory within their home folder, but that is unusual. In those cases, admin privs are not needed.

Hope that helps a tiny bit,

[janderson215]

That is helpful, thank you. Do you know of any official documentation that states that writing to the Applications directory requires admin credentials?

[talkingmoose]

That sentence from Apple’s documentation is not really complete.

Standard users can install drag-and-drop applications to their home folders but they cannot run Apple Installer packages to install software outside their own home folders or place anything outside their home folders (except for /Users/Shared and the Public folder of other accounts for sharing files and some temp file locations).

Admin vs. Standard is such a fundamental concept to macOS and operating systems in general that it’s practically understood as a given instead of something that needs defining. You’ll likely have a difficult time finding it more fully defined. If you’re a Standard user (without Admin privileges) you cannot modify the operating system, privileged areas like /Applications or /Library or access other user folders. If you’re an Admin user, you can do most anything.

[janderson215]

Thanks @talkingmoose. Another problem I find is that if I, as a standard user, download a DMG containing a .app file, I can move that .app file into Desktop or Downloads and launch the app. Is there a way to prevent this other than software blacklisting? It seems like that list would have to be really exhaustive and updated all the time like malware definitions to actually be useful.

I noticed another issue in adding certain restrictions. I can see that the Configuration Profile that disallows Disk Images from mounting has been deprecated. Is there a newer configuration setting that replaced this functionality, or are we unable to prevent DMGs from being mounted.

Thanks for any insight you're able to provide.

Jon

[mm2270 · Accepted solution]

@janderson215 You have a couple of options with this, but none of them are great, just to warn you up front.

The first option is, you can use a Config Profile to restrict applications from running from certain directories, such as blocking anything running from the /Users/ path. This can be found in the Restrictions payload of a profile, under the "Applications" tab. All the way at the bottom, check the box labeled "Restrict which apps are allowed to launch" and the options for Allow Folders and Disallow Folders will appear.

But be warned that this method often leads down a rabbit hole of needing to whitelist certain paths within those directories. Many applications like to place helper apps within the ~/Library/Application Support/ path, so if those aren't properly whitelisted to allow them to run, the helper apps will be blocked, meaning the apps either won't run at all, or will cause a bad experience. However, you can explore this option, since it can do what you're looking to do. Only you can decide if the amount of noodling with the profile to get the exact functionality you want is worth the trouble. I would recommend testing it out on test/IT machines a lot before trying to roll it out to your endpoints.

The second option I can think of would be to block some apps using Restricted Software, such as diskimagemounter, which gets run when a disk image is double clicked on to mount. The only issue is, some disk images mount so quickly that Restricted Software may not be able to stop the process in time before the disk image successfully mounts. Once the image is mounted, diskimagemounter terminates and is no longer needed. I've never tried this myself, but it may be worth exploring to see if it helps.

[janderson215]

This is a great answer, thank you! The disimagemounter "bug" might serve as more of a feature in some cases. We use TeamViewer which mounts a DMG containing a PKG and a plist (which applied during PKG installation). This method may continue to allow TeamViewer install/Patch Management updates.

[mm2270]

@janderson215

I actually did end up testing this, purely out of curiosity. I ended up creating 2 Restricted Software titles that seemed to do the trick. I'm posting screenshots of them here.

In my tests, these successfully blocked disk images from being mounted in the Finder with a double click operation. But because mounting a disk image on the command line uses a different process, those will still work, which most likely means (not tested) that a Jamf policy using a disk image as the package should still work. This isn't fool proof, because anyone with access to the Terminal and a little knowledge would still be able to mount the images and copy content off them. But it might act as a deterrent to casual app installs from the internet.

Hope those help.

[rubberchicken]

 .