Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Securely sign StartupScript.sh

Currently the Jamf script StartupScript.sh (in /Library/Application Support/JAMF/ManagementFrameworkScripts/) is distributed without secure digital code signing. Would it be possible to have this script be signed by Jamf when pushed to workstations? The same request would apply to any other scripts JSS sends to enrolled Macs.

Comment
Order by:

Posted: by howie_isaacks

I'm curious. What (if any) issues are being caused by these scripts not being signed?

Like

Posted: by mario

It was just a general improvement suggestion before, but with macOS 10.14's introduction of TCC, there's the additional merit of being able to authorize approved privacy settings for any policies this script executes that require such approvals. So, for example, if StartupScript.sh runs jamf policy -action startup, and one of the triggered policies attempts to run an osascript action that interacts with System Events, the user currently gets an alert to approve StartupScript.sh's System Events interaction. Signing the script with the same bundle ID used for other Jamf processes (see here: https://www.jamf.com/jamf-nation/articles/553/preparing-your-organization-for-user-data-protections-on-macos-10-14) would allow administrators to pre-approve such actions and avoid user-facing alerts without context.

Like

Posted: by daworley

I got hit by the "enroll" script that gets laid down as part of OTA enrollment biting me in a similar manner. This triggered some fun with timing between when the PPPC profile gets deployed and actions initiate by enrollmentComplete policies.

Like

Posted: by alexrobert

This is literally the only thing stopping us to deploying macOS 10.14 :(

Like

Posted: by HNTIT

I now have this working, and hope JAMF can adopt this simple textfile change as it helps massively.

The Complete Setup I have put in here is as follows.

#!/bin/bash
#
echo '@@ -11,4 +11,5 @@
        <key>ProgramArguments</key>
        <array>
+                <string>/bin/sh</string>
                <string>/Library/Application Support/JAMF/ManagementFrameworkScripts/StartupScript.sh</string>
        </array>' > /tmp/com.jamfsoftware.startupItem.diff
#
patch -u /Library/LaunchDaemons/com.jamfsoftware.startupItem.plist -i /tmp/com.jamfsoftware.startupItem.diff -F 1 -l -N -r /tmp/com.jamfsoftware.startupItem.rej

This updates the JAMF launch Daemon to correct the mis-identification of the parent process.

The best explanation i can find for the exact issues is here

I have run this script in a policy targeted at a smart group, the group checks if the OS is Mojave or Higher and also checks the status of the Extension Attribute below.

#!/bin/sh

file=/Library/LaunchDaemons/com.jamfsoftware.startupItem.plist
word="<string>/bin/sh</string>"

cmd=$(grep -c "$word" $file)

if [ "$cmd" != "0" ]; then
        echo "<result>PATCHED</result>"
else
        echo "<result>NOT PATCHED</result>"
fi

This works around the issues very nicely.

Again, i hope JAMF adopt this in the next release, as its a simple text change that more correctly sets up the launch daemon.

Like

Jamf wants to hear your feedback around Jamf Pro: LDAP Servers and Reports!