High Sierra blocking kernel extensions?

Is the Technical Note going to be revised soon?

TN2459 was updated for b3 on 12 Jul.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

GC,

I want to second the negative feedback that has been provided by others in this forum regarding this change. Although I get the intent of what you are attempting to accomplish from a security perspecitve, where this change fails is its UI design. In my opinion there are much better ways to design this user interface to handle the general case of legitimate applications that rely on kernel extensions, without compromising the security objective here.

The problem before High Sierra is that any application could attempt to activate a kernel extension at any time. In that case, this UI makes a certain amount of sense, as user interaction can be demanded whenever that happens to occur.

However, most applications that have kernel extensions do not load them randomly or unpredicably. What Apple has failed to do here is provide developers with a structured process that is easy for users to follow that legitimate applications and installers can use to guide users through approving kernel extenions at installation/setup time. As things stand, the only option is to pop up a window which attempts to explain the process to the user, tell them they are about to see an error message, attempt to load the extension so the error appears, and then attempt to show the user how to dig through the System Preferences to approve it. This is extremely cumbersome and will ultimately fail in practice.

In my opinion, for what its worth, applications should be able to direct the operating system to ask the user for approval directly in a pop-up dialog at install time, instead of requiring the user to find the approval switch within the System Preferences. Applications should also be able to obtain approval to load kernel extensions in the future before actually loading them, as loading them at install time may not be appropriate.

Regardless of whether or not your designers agree with those observations, the present UI appears to be designed to deter the loading of kernel extensions in general and the user experience in the context where kernel extensions must be loaded does not appear to have been given careful consderation. You must go back to the drawing board on this.

Thanks,

TC

Please file a bug on this at <https://developer.apple.com/bug-reporting> and post the bug number here.

The System Prefs approval UI is not supposed to disappear spontaneously.

--gc

I haven't experienced the UI disappearing. That was another poster.

My original complaint has been mostly taken care of: Our automated testing can use the recent changes to spctl, and after playing with things for a while I found that I was mistaken about things being on a per-driver basis. Once one of our drivers has been whitelisted, all of the ones sharing the same Team ID are also whitelisted.

So, really, the only sticking point for us now is the discontinuity introduced by users having to go to the Security Preferences panel. It is a bit disruptive. It would be nice if the warning dialog would give the user the opportunity to approve it then and there instead of having to later go to Security Preferences. Even better would be if the kextload command would pause until the response to the dialog (whether accept or deny) has been provided by the user.

To provide a different perspective: I'm happy to see the discontinuity, because it's creating a UI that is prioritizing security.

We live in a much different world than we did 10 years ago. Powerful botnets and well-funded hackers use persistent threats in the form of kernel modules to silently exploit unsuspecting users. And a rogue kernel module makes it very easy to work around the other protections in OS X.

While these threats are not as common on OS X as other platforms, they could be one day. A UI that makes installing kernel modules a bit harder is an excellent idea. 99.9% of users are not installing kernel modules, so making take a few extra steps is the right move. Each of those steps provides the user an opportunity to really think through if this is necessary.

For the remaining 0.1% of users (perhaps such as yours), the application they are installing is sophisticated enough where they should be able to successfully perform those extra steps. And there won't be a competitive disadvantage, because all products in categories where kernel modules are necessary will have the same UX.

I am glad that there is not a warning dialog that allows for immediate approval. I would not want that on my system.

Thanks.

Unfortunately, b3 does not match TN2459 when it comes to the Security & Privacy Pane behavior (Bug report already filed).

It does not explain how a daemon (or root process) can be informed that a kext is now running without doing some polling.

Sample code for I/O Kit and non I/O Kit scenarios could prove useful (and also proves that the feature works as expected).

FYI:

I want to revert the kext loading system policy state in order to test my application behavior when my kext is blocked.

I succeed to remove my identifier from the allowed kext list by the following procedure.

1. The system policy is saved into /private/var/db/SystemPolicyConfiguration/KextPolicy (sqlite3 file)

To modify the file, boot macOS in Recovery Mode.

2. Open Terminal in Recovery Mode, then open the file by this command.

sqlite3 /Volumes/<YOUR VOLUME NAME>/private/var/db/SystemPolicyConfiguration/KextPolicy

3. Confirm contents by these queries.

sqlite> .tables

sqlite> SELECT * FROM kext_policy;

sqlite> SELECT * FROM kext_load_history_v3;

4. Delete policies by these queries. (Replace 'G43BCU2T37' with your team_id)

sqlite> DELETE FROM kext_policy WHERE team_id = 'G43BCU2T37';

sqlite> DELETE FROM kext_load_history_v3 WHERE team_id = 'G43BCU2T37';

5. Exit sqlite by control+D. Then restart macOS.

Thanks for sharing the information.

So it might be worth disabling SIP on a development machine to avoid repeatedly booting in Recovery Mode to remove the team ID.

Disabling SIP to be able to edit the database outside of recovery mode is not an option as it also disables the SKEL system. Sigh.

Hello. I’ve reviewed TN2459 and I’m left with a really big question.

How can enterprise software packages be deployed and run that use KEXTs if the desktop end user—who has no clue what these deployed packages are—can deny access?

We make an enterprise level digital forensics and incident response package that runs on macOS, and the endpoint agents are deployed from our server through a push mechanism. There is no interface at all for the end user; this is an enterprise tool that is run through the IT Security staff. In fact, in most cases, they don’t WANT the end users to know our tool exists.

If we push agents and the end users have the ability to decline them, how can enterprise software rules be enforced? Am I missing something in the technical documentation that covers enterprise software deployments?

Thank you,

John

So, if I read the updated technote correctly, the solution for enterprise deployments is to manually boot each computer into recovery mode to issue commands to allow kernel extensions on a per-machine basis?

One of our customers has over 10,000 Macs in deployment. How is their IT team supposed to walk around and do this individually on 10,000 Macs? Similarly, if they don’t do this, then when IT pushes our software package out to the endpoints, every user is going to be left with the decision to allow our kernel extension? For a security package that the end users aren’t even supposed to really know about? That has no GUI whatsoever?

I get completely what you’re trying to do here, and the effort is a noble one, but while it works brilliantly in a single-owner environment, it becomes absolutely unusable in a large enterprise environment under the current technote definitions. Ask yourselves how an enterprise user with 10,000 Macs is supposed to push mission critical security software that the end-users are not supposed to be able to defeat, and please understand that an IT team manually booting 10,000 Macs into recovery mode to change settings isn’t going to work.

You can't disable only some protection: "csrutil enable --without fs --no-internal" . See "csrutil status" afterwards.

Like this you can alter "/private/var/db/SystemPolicyConfiguration/KextPolicy" outside of the recovery mode and still have "Secure kernel extension loading" policy protection.

FWIW, I found that non-Apple products -- minimally my Logitech G502 mouse -- cannot be used to click on the "Approve" button from the Security & Privacy pane. Instead, use of an Apple trackpad or mouse, was required.

In console, I found:

com.apple.preference.security.remoteservice Dropping mouse down event because sender's PID (112) isn't 0 or self (423)

https://discussions.apple.com/message/32992230?ac_cid=op123456