Deny uninstalling SystemExtension for root

Hi,

I face the same issue.

I noticed stance behaviors :

• Terminal commands such as rm and mv are managed when rename or unlink/truncate events are denied.
• Finder usage (as described in your post) used to work for some time (Finder always trigger rename events) but is failing since 12.4 (and 12.5 betas)
• There’s no event for disabling the extension from System Preferences (kext event do not apply)

If somebody has some hint here it is welcome.

Regards,

Jerome

I believe the issue here is that the Finder is system extension aware, so it disables your sysex before moving the app.

With regards your high-level goal, the original poster wrote:

I want to prevent the root user from uninstall my EndpointSecurity System Extension.

I presume they meant “an admin user” rather than a “root user”, because macOS does not, in general, allow root to log into the GUI. However, I’d like to get more context from you. Specifically, are you trying to prevent this on normal user systems? Or on managed systems, for example, Macs being managed by MDM?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes it is likely that root was used to mean admin.

Standard users cannot disable SysExt so there’s no issue for them. MDM configuration profiles (user-accepted or DEP) can whitelist the SysExt but cannot prevent unloading.

Maybe this is related to the complexity of integrating with Finder or other dynamic unloading/reloading of SysExt.

Anyway MDM policy could be a way to deal with it. SysExt delegate maybe also (to be seen which process would have to host the delegate).

But my surprise is mainly that I should be able to deny moving app2 to trash if my SysExt is hosted in app1. This has worked for some time but fails as of 12.5. I filled a feedback FB10168135.

Regards,

Jerome

About using an Agent as Extension Manager Delegate.

I tried using an Agent (XPC Service) hosted in the System Extension’s host app.

Then I have something like:

Container.app

• /Contents/Resources
• /Contents/Library/SystemExtensions/Extension.sysext
• /Contents/XPCServices/Agent.xpc

The agent cannot load the system extension (error ‘extension not found’).

This seems coherent with documentation stating that extensions are searched at /Contents/Library/SystemExtensions from main bundle. XPC Service’s main bundle is the Agent.xpc above.

However I noticed that the OSSystemExtensionRequest has a nil attribute named _containingApplication this looks like container app support is somehow planned.

Also there’s an error OSSystemExtensionErrorUnsupportedParentBundleLocation in the Framework which hint again at nested bundle support.

Did I missed something. Is there a way to say to SystemExtension Manager that it need to look at the XPC’s container app bundle instead of own bundle ?

Sorry my ascii art is broken for bundle hierarchy.

I tried using an Agent (XPC Service) hosted in the System Extension’s host app.

You mean container app here, right?

When Apple talks about plug-ins:

• The container app is the app in which the plug-in resides.

• The host app is the app using the plug-in.

The latter doesn’t really exist for a sysex — the host ‘app’ is the OS itself — but we still use the former.

However I noticed that the OSSystemExtensionRequest has a nil attribute named _containingApplication this looks like container app support is somehow planned.

I can’t comment on the future but I will say that you should not try to draw conclusions based on private properties like this.

As to your main question, I’m going to repeat what I said here: The SystemExtensions framework is intended to be used by a GUI app to load and unload system extensions in response to user actions. I’m not sure why you want to defer that work to an XPC service but it’s not in line with our expectations and so I’m not surprise that it doesn’t work.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks Quinn for this very clear confirmation.

I’m not sure why you want to defer that work to an XPC service but it’s not in line with our expectations

The problem I try to solve is the same as the original subject of the thread ‘Deny uninstalling SysExt’. In particular when disabled from System Preferences.

The problem I try to solve is the same as the original subject of the thread ‘Deny uninstalling SysExt’.

OK. But how are you imagining that an XPC service could help with that?

Coming back to the big picture, I’d like to get a clear answer to a question I posed earlier: Are you trying to prevent disabling the sysex on normal users systems? Or on managed systems?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

In my case it’s about managed Macs.

In my case it’s about managed Macs.

OK, cool. In managed environments configuration profiles are ‘king’. If the current configuration profile facilities are not doing what you need them to do, I recommend that you file an enhancement request describing your requirements. Everything else is just workarounds.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Here it is : FB10332955