Mojave Privacy Preferences Prompt - ssh recon

Just bringing this back the top of the list, as a lot of stuff has been posted since created this.

@kerouak or @mike.paul do you have any thoughts?

Thanks

Since it specifically references Enterprise Connect and only happens on recon, my first suspicion is a script in an Extension Attribute is doing something to manipulate Enterprise Connect (maybe an AppleScript tell block or something?). If you can't change the EA script to work around that, adding a PPPC profile which only allows sshd-keygen-wrapper to send events to Enterprise Connect may be sufficient?

I will add that we don't use Enterprise Connect so there may be a larger security concern that I'm not thinking of.

EAs ran on normal check-in would be asking for access but likely being denied since no prompt would be given. The prompts are pretty accurate representations of what would be shown in the tcc logs for what it sees as the parent process:

##to see current requests
/usr/bin/log stream --debug --predicate 'subsystem == "com.apple.TCC" AND eventMessage BEGINSWITH "AttributionChain"'
##or to see previous requests (doesn't show full history, just recent history - still investigating what resets this)
/usr/bin/log show --predicate 'subsystem == "com.apple.TCC"' | grep Prompting

But I would guess that you would need to whitelist the Jamf binary (for normal check-in policies) and the jamf agent (for self service recons) using the AppleEvents service to communicate with Enterprise Connect as the receiver (I don't have that so I can't provide the identifier or code requirement of EC).

Now this specific allowance of Jamf > Enterprise Connect would not cover Jamf polices ran via terminal or while SSH'd in since that would be shown as the parent process per apple (terminal>jamf>enterprise connect or ssh>jamf>enterprise connect). You could whitelist terminal and/or ssh but as you had noted that would be negating the point of these new security settings.

@mike.paul Users do actually get prompted in this case (running recon via SSH and having an extension attribute that calls a cl utility like eccl)

This obviously limits the functionality of EA's in that you cannot use these app cl utilities to populate said EA's.

Either that, or just remind people to never run recons over SSH :).

Just remembered that it bears mentioning that this cl utility runs in the user context. Here is the EA in question:

user=$(stat -f %Su "/dev/console")

status=`su - "${user}" -c '/Applications/Enterprise Connect.app/Contents/SharedSupport/eccl -p signedInStatus'`

    echo "<result>$status</result>"

Thanks again for your help.

@mike.paul Are you aware of a way I could identify within this EA whether or not the command is coming from ssh and just skip running the eccl command if so?

That way, the EA would still work under normal circumstances when the jamfagent checks in but could potentially just skip running it when the recon is originated via ssh.

Just trying to think through different scenario's to keep things working.

Thats a good question. I do see a few possibly methods after doing a search, one possible solution is checking $SSH_CONNECTION, when ran locally it doesnt report anything, when ran while SSH'd in I see -bash: My:IP:Address:Number command not found so but I haven't done any testing around this.

thanks @mike.paul I am wondering if the return from this command is not actually interpreted as a return or just an error? I am having trouble getting the ea/script to behave differently depending on the connection. Either that or something is wrong with my syntax. Does anything jump out at you? I have been looking around for an alternative way to get ssh connection info but so far have been unsuccessful.

#!/bin/bash

ssh=`$SSH_CONNECTION`
user=$(stat -f %Su "/dev/console")
status=`su - "${user}" -c '/Applications/Enterprise Connect.app/Contents/SharedSupport/eccl -p signedInStatus'`

if [ "$ssh" != "" ]; then
exit 0 
    else   
     echo "<result>$status</result>"
fi