Deploying an application that requires KEXT

[thegooch49]

Hello, I'm deploying a new app that contains a .kext file. This causes the security exception window to pop up. I've created a Configuration Profile with an "apprroved kernel extension" section w/ the team ID to avoid the security messages. I need this profile to hit the systems before the install, to avoid the security message.

Since I can't add a Config Profile to a policy, what is the best way to do the profile and app with one self service entry? It seems that packaging up the config profile and installing it with a postinstall script might be the best option here. Previous posts on this were fairly old, so I figured I would re-ask the question. Is this still the best bet?

[tak10]

Can you deploy the Configuration Profile with Approved Kernel Extension to all computers prior to the install?
I had developers that need to run VirtualBox so I just went ahead and deployed configuration profile to approve virtualBox kernel extension to all computers. As far as I know, it's not causing any issues on the non-developer macs without VirtualBox installed.

[thegooch49]

I suppose I could, but that seems a little messy. I want to deploy the application via self service 'as needed' by the end users. It doesn't make logical sense to push out the configuration policy everywhere, when a subset of people will be installing the app.

[Phantom5]

You could put you configuration profile in a package with a post install script that uses the the profiles command to install the configuration profile, add that package to your policy and make sure it installs before installing your app.

[thegooch49]

I ended up packaging and deploying with a script. I'm hitting an error when the script runs that says the following:

profiles install for file:'MyProfile.mobileconfig' and user:'root' returned 13 (The profile must originate from a user approved MDM server.)

I have an approved MDM profile installed. I can deploy the KEXT whitelist profile fine from the MDM, but other methods (scripted install) seems to fail.

[ShaunRMiller83]

The way I've handled similar situations was to:

1) Create the policy like I would with any other app in self service
2) Add an execute command function in the policy to run something like touch /var/db/.AppWatermark; jamf recon
3) Create an extension attribute using the logic below to look for the watermark

#!/bin/bash

if [ -f "/var/db/.AppWatermark" ]; then
        result="Present"
        echo "<result>$result</result>"
else
        result="Not Present"
        echo "<result>$result</result>"
fi

4) Create a smart group 5) Scope Config Profile to the Smart Group

It may be a bit more setup upfront but I've found it more manageable long term.

Of course everyones mileage will vary.

[NowAllTheTime · Accepted solution]

The approved kernel extension payload must be pushed via an APNS transaction from the MDM server to a Mac that was either enrolled via DEP or has a User Approved MDM profile. A profile with this payload will not work if it is installed via script and/or package - the only way around the error you are getting is going back to pushing the profile from the server.

It may not make sense to push an app specific profile to every machine if not every machine is going to run that app, but you could do something similar to what we do in our environment: Generically name a profile something like "Approved Third-Party System Extensions" and put the target team ID in the approved kernel extension payload. The small handful of users that happen to look at the Profiles pane in System Preferences tend to perceive this as just a general security related enterprise profile, and don't get annoyed about having a profile related to an app they don't have installed. This generic kernel extension profile can then also be updated occasionally whenever you have other apps enter the environment that you need to whitelist the kext for and that way you don't end up needing to manage a bunch of separate kernel extension related profiles for separate apps.

[thegooch49]

Thanks @jasonaswell . That makes sense. In my head, I had 'one profile per whitelisted app' and push them out together. My understanding of what you described, is a single policy w/ all the whitelist groups in it that goes everywhere. A new application that needs whitelisted is not a new profile, just an addition to the existing profile that would get pushed out again when updated.

Thanks for the ideas everyone, I think I'm sold on this.

Jeff

[rhooper]

@jasonaswell Thanks.

I am having issues with the VirtualBox being loaded. I create the package, but it does not run without the app being approved in privacy and security, which in our environment is blocked.
My questions are: What is the Team ID?
How do I locate the Display name?
And the Kernel Extension Bundle?
Are there any JAMFers that can help me learn where to locate these items?

Thanks all,
~r

[Hugonaut]

@rhooper - https://www.jamf.com/jamf-nation/discussions/29646/how-to-kernel-extension-in-high-sierra

[rhooper]

@Hugonaut that is awesome.

When I use the SQL Select function do I want to name it directly or just let it run its stuff and I can locate it?

[Hugonaut]

@rhooper yes it is. After you asked, I went looking and couldn't find anything, figured what the hay, I've looked before & I'm sure a lot of other jamfers have...

To answer your question Just run the commands exactly as typed, it will pull all KEXTS and associated IDs in the database and then you can add them, you don't need to name anything directly

[rhooper]

@Hugonaut Worked like a charm. Now I can push out the VBox app. Thanks

[ebrowning]

How are we supposed to whitelist apps without an MDM? I refuse to pay thousands of dollars a year for something I can do for free with Munki. I tried the PPPC utility but it moans about wanting a user approved MDM to use the profile. This is utter nonsense.

[larry_barrett]

[ebrowning]

Thank you for the useless response.

[KrisMallory]

@ebrowning There are free mdm options out there that can provide just the barebones of what you need to do.

Keep in mind one of the reasons Apple has been moving towards mdm required settings are so that only enterprise owned (or user management acceptance) is to prevent hijacking attacks.

I just did a quick search and found this open source project that seemed like it might work for you if you're not interested in paying for the tech support, continuous development, and 0 day features that Jamf and other premium mdm's provide.

https://micromdm.io/

Good luck!