4

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.

Improve this question
6
  • 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
    Commented Nov 24, 2020 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
    Commented Nov 26, 2020 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
    Commented Nov 30, 2020 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
    Commented Nov 30, 2020 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
    Commented Nov 30, 2020 at 21:58

4 Answers 4

Reset to default
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.

Improve this answer
2
  • 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
    Commented Nov 25, 2020 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
    Commented Nov 25, 2020 at 22:47
1

You're going to have to disable SIP by rebooting into Recovery Mode, opening up a terminal window (click Utilities > Terminal in the menu bar), and typing "csrutil disable." Then, reboot to get out of Recovery Mode and proceed to unload and delete the remaining kext files. As of 10.15 (MacOS Catalina), kernel extensions have been put in 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 folder's protection (SIP) and then proceed to unload whatever kexts you don't want.

Be sure to re-enable SIP after you're done (do the same thing as before, except type "csrutil enable" instead of "csrutil disable").

Also, a while back (on either MacOS El Capitain or MacOS Sierra, I don't remember which right now), it was possible to disable kexts using the same terminal window which you used to disable SIP (Recovery Mode) or Single User Mode. In order to enter single user mode, reboot and hold down ⌘S while starting up. In order to enter recovery mode, reboot and hold down ⌘R.

I advise caution whenever dealing with system parameters; some may render the system unoperational, or at least some of the services that are offered could be severely hampered.

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

Improve this answer
1
  • The aim is to prevent even root users from uninstalling our app on their mac. > This is actually quite simple and you could reinforce this policy using a Machine Device Management System such as Jamf (jamf.com)
    – Rake
    Commented Nov 23, 2022 at 19:10
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.

Improve this answer
0

Kernel extensions (KEXTs) can prevent the system unloading them. As it's not always a good idea to unload a kernel extension currently in active use, it may freeze the entire system or panic the kernel if you do, a kernel extension is asked prior to unloading if it is okay with that and if it denies, the system won't unload it. Of course, a KEXT can simply always claim unloading would be a problem. So I cannot unload it from a running system.

And a KEXT can hook itself into the file system API to monitor all file access and prevent certain kind of file operations, e.g. one that would delete the KEXT itself on disk or any user space helper tool (agent/daemon).

So on first glance, that system seems bulletproof. But it isn't. E.g. nothing stops me from booting into single user mode and delete the KEXT in that mode. Nothing stops me from booting the recovery system and deleting the KEXT on the main partition. Nothing stops me from booting from an external drive and delete the KEXT on the internal one. And once deleted, I can just boot the internal system normally and nothing will stop me from removing any other software I dislike.

This is just something maleware cannot easily do and also not without the user in front of the computer noticing it. So this stops malware and thus makes sense for a virus scanner but it doesn't stop a human being sitting in front of such a machine from doing it.

Even SIP can only protect an actively running system. I can boot into recovery mode and tamper with any files I want, even those usually SIP protected. And SIP protection is not available to third party developers, it's a protection system intended do protect macOS itself from being tampered with by malware and hackers.

And since KEXTs are obsolete with macOS 11 and the upcoming macOS 12, this is no solution I would even consider to begin with.

Improve this answer

You must log in to answer this question.

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