Skip to main content
Jamf Nation, hosted by Jamf, is a knowledgeable community of Apple-focused admins and Jamf users. If you like what you see, join us in person at the ninth annual Jamf Nation User Conference (JNUC) this October for three days of learning, laughter and IT love.

Deploying an application that requires KEXT

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?

Like Comment
Order by:
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by f.deis

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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by 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.

Like
SOLVED Posted: by jasonaswell

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.

Like
SOLVED Posted: by 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

Like