2

The aim is to prevent even root users from uninstalling our app on their mac.

Apparently, many security applications have this sort of functionality wherein a user(even with root privilege) can not uninstall or tamper with the agent on their machine.

I tried tampering/deleting an antivirus app on Catalina but I failed and noticed a few interesting things:

  1. It has a kernel extension. But I can not remove the kernel extension(as root).
    #kextunload /Library/Extensions/xxx.kext
    (kernel) Kext com.xxx.kext did not stop (return code 0x5).
    (kernel) Kext com.xxx.kext can't unload - module stop returned 0xdc008017.
    Failed to unload com.xxx.kext - (libkern/kext) kext (kmod) start/stop routine failed.
    
    
  2. The application is installed in /Library directory rather than the usual /Applications directory.
    drwxr-xr-x    7 root  wheel   224 Oct 28 14:40 xxxx
    

The folder does not have any extended attributes. I can not delete this folder or any of its subfolders and getting permission denied error even as root.

  1. The app has a bunch of launchdaemons but I can not remove them (again tried as root)

    #launchctl remove com.xxx.xxx. 
     Not privileged to remove service.
    
  2. Tried killing the processes, again operation not permitted.

  3. The app comes with an uninstaller which can somehow uninstall the app, but it needs a special password (separate from system password) to be entered to work

Many of Apple's own apps and services have this sort of behavior but they come with the system and are backed up by System Integrity Protection.

How can a third-party app achieve this sort of behavior? This is not unique to this particular application but antivirus have similar sort of features. Any insight on how to achieve this..

Note: Ours is an enterprise app that will be installed on machines owned by the companies and managed by IT but end users will have root access on their machine.

  • 4
    Note that root on Mac doesn't have privileges above those of any admin (sudo) account. It isn't a $DEITY account like unix. It's also disabled by default. – Tetsujin Nov 24 '20 at 17:55
  • The app will need the com.apple.rootless.install entitlement. Don't know if Apple gives this to anyone - maybe for security softwares like anti-virus. – sfxedit Nov 26 '20 at 23:49
  • @sfxedit If this is being set up without SIP (to be turned on later), what prevents you from granting yourself the entitlement? – Wowfunhappy Nov 30 '20 at 3:51
  • @Wowfunhappy - Entitlements are embedded in code signature ... if one modifies a signed-binary in any way, this will make its digital signature invalid, which in turn will invalidate its entitlements (such as com.apple.rootless.install). The rootless entitlement comes into picture only with SIP enabled. I am guessing only apple signed binaries are allowed to use this entitlement, which will be verified as soon as SIP is enabled. – sfxedit Nov 30 '20 at 20:30
  • 1
    You can grant yourself private entitlements by disabling SIP & AMFI: strv.com/blog/unlocking-marzipan-uikit-on-macos. So my thinking is, you could (1) disable SIP and AMFI, (2) run an app with the com.apple.rootless.install entitlement, which (3) sets SIP protection on some other app, at which point (4) you could re-enable SIP. This feels like it should work in theory... (not that I'm saying any of this is a good idea!) @sfxedit – Wowfunhappy Nov 30 '20 at 21:58
6

The aim is to prevent even root users from uninstalling our app on their mac.

You as a 3rd party developer can't prevent the root user or users with root privileges from uninstalling apps that they, technically, can install themselves. What one one admin can do another can (un)do.

The core OS is protected by SIP and if using Catalina or later, the system volume is read only. This is implemented at the very base layer and not at the application layer where you operate.

IT, however, can manage permissions, rights, and roles through the use of MDM (Mobile Device Management) software. Once a device is enrolled, IT will be able to create and enforce policies allowing/disallowing software use and installation.

This is for IT to manage, not the developer.

  • In general, agree with your answer. But this is a specific requirement where users have root privileges and so can override MDM settings configured by the IT. Hence, IT wants the product to have this capability. As explained in my question, many endpoint security products are giving this functionality. – Siva Prakash Nov 25 '20 at 4:10
  • 1
    IT wants the product to have this capability. Sometimes, it's simply not feasible to implement what they want. Consider that even security software with agents running as background processes, locked down by IT are not absolute. Even though the agent was supposed to prevent disabling/uninstalling, some users would find ways to do so. The remedy is to have a report run to see when it last communicated back and if it was past X number of days, we would push the agent back to the end device which would then reinstall the software. It also initiated a trip to HR for the employee. – Allan Nov 25 '20 at 22:47
0

I do not recommend trying to lock down administrators. It’s much better to manage admin access, but if you insist you want to swim in the opposite direction from Apple, start with a product like DeepFreeze.

Their Mac management solution is the best of you want to sacrifice the more efficient modern ways to control changes. Now, once you price out that software or underwrite a “built it again ourselves solution”, look again for Apple to partner and get acquainted with how well DEP and MDM work to achieve all of your goals and not just the unintentional modification of files issue.

What you are after is MDM supervision and device enrollment. That is the efficient and modern way to secure corporate assets and as a benefit, your IT enrollments will be zero touch and enforced by Apple. Mojave and newer are quite well designed and Big Sur has some massive levers to further secure against file modification out of the box even without DEP+MDM.

Apple offers free advice and consulting to get any business started down this path and offers paid professional services any time you want first part support or enhanced services past the basic free accounts needed to properly secure all devices (Mac / iOS / iPadOS / tvOS / watchOS).

By enforcing code notarization and signing, you lock down all the modifications whether malicious or user generated.

0

you're gonna have to disable SIP by rebooting into recovery opening up a terminal window and "csrutil disable" (then reboot into the OS) and proceed to unload and delete the remaining kext files. As of 10.15(catalina) kernel extensions have been put on the /System/Library folder and only mirrored(or symlinked) into the /Library folder. Thus, in order to change the system parameters; you'll have to disable the /System's folder protection (SIP) and then proceed to unload whatever kexts you're not gonna use.

Be sure to re-enable csrutil (Same method as before though; utilize the command > csrutil enable)

Also, a while back(El capitain or sierra [don't remember right now and its been a while since i've disabled the unecessary garbage that comes preloaded with OSX]); anyhow; -- it used to be possible to disable kexts thru the same terminal on which you could disable SIP (recovery mode) or Single User Mode. In order to enter single user boot with cmd+s in order to enter recovery boot with cmd+r

I advice caution whenever dealing with System Parameters; some may render the system unoperational; or at least...some of the services that are offered could be severly hampered.

Another possible route would be thru the installation of "Provisioned Configuration Profiles" which bypass/block internal processes (as if they'd be installed by an organization or an MDM).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .