Issue: Jamf Pro Policy Install - Passed Parameter API Creds Plain Text Exposed in Policy

[blakeusblade]

Using Jamf Pro here.

Passing paramaters in thescript to deploy super is great, however exposes the API creds in the policy.

And at present, due to another issue (API permission requires Computers > Create/Read) is somewhat of a security hole.

Issue: API - Computers Create and Read Removed - Super doesnt run https://github.com/Macjutsu/super/issues/36

[iDrewbs]

I added a piece to the script to use the encrypted strings to pass an encrypted version of the password. It might be useful if we could get this functional permanently added to the script to be more secure.

[rchase254]

It's my understanding that the create and read permissions are needed to acquire the computer's jamf pro ID. Couldn't we avoid needing to reach out to the jamf pro API to get that information by piping the jamf recon binary into awk to grab the ID that gets printed at the end?

something like:

jamf recon | awk -F ">" '{print $2}' | awk -F "<" '{print $1}'

should return the computers jamf pro ID and avoid the need to do an API call for that info.

edit: this doesn't really fix the problem with storing the API creds in plain text, but it should reduce security risk by eliminating the need for unnecessary API permissions.

[Macjutsu]

@blakeusblade @iDrewbs I am not a fan of encrypted strings, as it adds complexity without providing any real security value. You either have a secret visible in Jamf Pro (where arguably only your trusted administrators should have access) or you put different clear text secrets (hash/salt) hard-coded in to the super script. Remember, the super script is "permanently" installed on the local Mac drive, thus your hash/salt secrets will literally be knowable by anyone with super installed.

@rchase254 I am aware this is likely a better method, but at this point for super v3.0 I'm focused on support for full upgrades. That being said, I do plan to implement this in a future version of super but I need to make sure it's backwards compatible with the current method to provide the JSSID in the Config Profile. Context in wiki.