Mojave Privacy Preferences Prompt - ssh recon

ocla__09
Contributor

I have a couple extension attributes for Enterprise Connect that utilize the EC command line utility (/Applications/Enterprise Connect.app/Contents/SharedSupport/eccl).

During Mojave testing, I have noticed machines get a privacy prompt when I run a recon remotely via SSH on a machine.
e75c4db6ba234df9924c7f707c8408c2

The first instinct is to create a privacy prefs policy for sshd that gives it access, but that seems like it could open up a security issue.

Has anyone run into something similar or have any ideas?

8 REPLIES 8

ocla__09
Contributor

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

ocla__09
Contributor

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

Thanks

bvrooman
Valued Contributor

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.

mike_paul
Contributor III

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.

ocla__09
Contributor

@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)
38df146dcd494824a7fe65826faf2314

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.

ocla__09
Contributor

@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.

mike_paul
Contributor III

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.

ocla__09
Contributor

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