Jamf + PPPC + Catalina

cbrewer
Valued Contributor II

Am i right in finding that the jamf binary needs "Full Disk Access" to be able to enable or disable ssh in Catalina? Is there any downside I should be aware of before using a PPPC profile to give jamf that access? Or any plans by Jamf to include "Full Disk Access" in their default PPPC rules for the jamf binary?

10 REPLIES 10

mike_paul
Contributor III
Contributor III

Hello @cbrewer, You are correct that the parent process turning on SSH needs Full Disk Access in Catalina.

Thankfully the default profile pushed by Jamf has SystemPolicyAllFiles/Full Disk Access granted so its good to go.

We did notice when that beta that turned this on shipped that our method to turn on SSH at enrollment and startup were via un-signed scripts so the process didn't work but we got our fix for that into beta 2 of Jamf Pro 10.16.

Until then you can always turn on ssh via a command in a policy: jamf startSSH

And as an FYI, when you use Jamf Remote or SSH into a computer the parent process is actually sshd-keygen-wrapper. That automatically gets added to Full Disk Access every time you SSH or Remote in.

If your end users are admins and go into Security & Privacy > Full Disk Access and just uncheck the box for sshd-keygen-wrapper, Jamf Remote would fail to mount SMB/AFP shares on macOS 10.16 computers and policies would fail. If they were to remove sshd-keygen-wrapper from the list using the minus symbol it would just be added back at next remote connection and Remote would function fine. If you are concerned about that you can ensure that doesn't happen by moving to an HTTPS distribution point. Or a more extreme method would be to push out a PPPC profile that whitelists sshd-keygen-wrapper for SystemPolicyAllFiles.

cbrewer
Valued Contributor II

Thanks @mike.paul - that explains quite a bit. So if I run "systemsetup -f -setremotelogin off" with a policy, it's not working because it's not being run by sshd-keygen-wrapper? But if I give the jamf binary "Full Disk Access" it does work. Is there a jamf binary command to turn ssh off?

mike_paul
Contributor III
Contributor III

Running systemsetup -f -setremotelogin off should work via a policy since Jamf has Full Disk Access with the default Privacy Preference Policy Control profile pushed out via Settings > Computer Management > Security > Automatically install a Privacy Preferences Policy Control profile (macOS 10.14 or later). But settings pushed via PPPC profiles are not shown under Security & Privacy.

There is not a flag in the Jamf binary to disable SSH that I know of. Also, sshd-keygen-wrapper shouldn't come into play with running the systemsetup command though.

I am not sure why it wouldnt work for you. I just tested with just the default Jamf profile and I sent that command via the Policies' Files And Processes section and it worked successfully via check-in and Self Service. If I remove the default Jamf PPPC profile I get the following error in my policy log and Remote Login is not disabled:

Running command sudo systemsetup -f -setremotelogin off...
Result of command:
setremotelogin: Turning Remote Login on or off requires Full Disk Access privileges

.

For more clarity on the sshd-keygen-wrapper, that would only need to be whitelisted for Full Disk Access if you use Jamf Remote or ssh into computers and you run a policy that needs to mount an AFP/SMB share and you were worried that someone would go into settings and disable it. By default when you connect via SSH that gets added to Full Disk Access automatically.

The discussion here might help shed some more light on sshd-keygen-wrapper: https://discussions.apple.com/thread/250352651

cbrewer
Valued Contributor II

@mike.paul I'm getting "Turning Remote Login on or off requires Full Disk Access privileges" with Jamf's default PPPC profile installed. But, I also don't have the jamf binary listed under Full Disk Access. Bug?
db3b536260054621b4a764fbad9bb011

mike_paul
Contributor III
Contributor III

Yea, this is a common confusion point. Your only methods to verify whats installed/controlled via mdm deployed configuration profiles is to look at the Profiles pane in System Preferences for the payloads pushed down or look at the MDMOverrides.plist with the following command:

/usr/libexec/PlistBuddy -c "print" /Library/Application Support/com.apple.TCC/MDMOverrides.plist

FYI, Terminal needs Full Disk Access/SystemPolicyAllFiles to read that file otherwise you get the message Error Reading File: /Library/Application Support/com.apple.TCC/MDMOverrides.plist. So basically it's a chicken or the egg scenario, you need TCC access granted to read MDM TCC applied settings. Fun times.

Whats displayed in System Preferences > Security & Privacy > Privacy are only the decisions end users made with prompts presented to them and not settings pushed via Profiles. Its essentially displaying the values that are stored in the TCC databases that can be found at /Library/Application Support/com.apple.TCC/TCC.db or ~/Library/Application Support/com.apple.TCC/TCC.db

cbrewer
Valued Contributor II

Thanks @mike.paul. I think I got caught by a couple of things. One is the bug you mentioned where turning ssh on at startup isn't currently working. The second is that I was triggering a check-in by running "jamf policy" in Terminal which also requires adding Terminal to Full Disk Access.

Heavy_D
Contributor III

@mike.paul so currently how have you been able to get the sshd enabled on the Catalina machines through JAMF?

My current script exits at 0 but never adds or enables sshd under the privacy & security system preferences.

Script result: Starting...
[31mWarning: macos 10.14 and later only allows control if Screen Sharing is enabled through System Preferences.
[0mActivated Remote Management.
Set the client options.
Setting allow all users to NO.
Done.
Starting...
[31mWarning: macos 10.14 and later only allows control if Screen Sharing is enabled through System Preferences.
[0mActivated Remote Management.
Set the client options.
Done.
Starting...
Administrator: Set user remote control privileges.
Administrator: Set user remote access.
Done.
Starting...
Stopped ARD Agent.
Done.

myronjoffe
Contributor III

@mike.paul Is this also related to the following scenario we also discovered later in the beta:

Skype for Business 16.28.120 part of our DEP provisioning policy prompts 'sh' (binary) wants access to control "System Events".
It adds an additional 2 mins to our provisioning workflow due to the prompt waiting for the users input behind SplashBuddy...

7b07a0f155a24bbaadf26589079b1184

mike_paul
Contributor III
Contributor III

@JarvisUno, as I mentioned above, I was successful in enabling ssh using jamf startSSH via a policy. Until Jamf Pro 10.16 comes out with a fix for enabling at Startup and Enrollment thats the ticket. I can't speak to your scripts results as I don't know what's in it and Im typically not one to troubleshoot peoples scripts.

@myronjoffe, Id maybe reach out to Skype to try to see what they changed. But yea, the script is probably the parent process so sh needs access to systemEvents, which is typically used for prompts to end users which shouldn't be popping up during provisioning anyway. But you could try allowing sh to talk to systemEvents via the Apple Events connector in PPPC and push that profile out during the DEP enrollment. 3b8bd947008642629810e72ccc03757f

myronjoffe
Contributor III

Thanks @mike.paul I've tried reaching out to the Skype team on Slack but heard recently that one of their lead devs who has been with MS for ~30 years recently packed up and left...

Im not that comfortable with giving /bin/sh to System Events if it can be avoided. Will log this with MS :)