How to implement Terminal - Secure Keyboard Entry

[alaiuppa]

Happy Monday everyone,

I'm currently going through the process of implementing the CISCAT benchmarks for Security, you can take a look at some of the features here if you are unfamiliar.

I am trying to make it so that I can deploy SecureKeyboardEntry to the terminal.

The best I could come up with is making a script to edit the PLIST and then pushing that script via policy.

defaults write /Users/$USER/Library/Preferences/com.apple.Terminal.plist SecureKeyboardEntry 1

The bit seems to work in having the setting checked off, however it also seems to remove whatever terminal customizations the user has.

Anyone have any recommendations for implementing this?

[mm2270 · Accepted solution]

@alaiuppa Taking a guess here, when you say the command above is wiping out user customizations, I'm thinking it may be because when the script runs and writes into the plist file, its changing the permissions on the plist to be owned by "root", so the user can no longer write to the plist file, and Terminal may end up creating a new one for the user on next run, with default settings in it (as opposed to the previous customizations)
As I haven't run any tests on your command, this is only a guess.

There are a couple of things you can consider here. One, you can make sure after the script runs, it changes the permissions on the plist file for the user so Terminal won't have trouble accessing the settings. Basically you'd make the file owned by the user, and make sure it has read/write for that account.

Two, you could try converting the above setting into a Configuration Profile, if your JSS is set up to deploy those. I would look at either using mcxToProfile, or simply creating the plist file with that one setting in it and uploading it to your JSS as the basis for a Custom Settings profile payload. I have a feeling if its deployed as User level config, it would work. Using a Profile has the advantage of being able to control it better than just modifying the user's plist file directly.

Hope that helps.

[alaiuppa]

@mm2270

Great reply, thanks!

I'm going to start with checking permissions first. Otherwise the Configuration profile option could work, I just seek to not overwrite the users existing PLIST for fear that it may erase some custom settings of theirs.

[mistacabbage]

Thanks for the help on this one. I made configuration profile with just the one setting and it worked when scoped to install for Computer. I tested on macOS 10.12.4 with with multiple users on the Mac and secure keyboard entry was checked in Terminal for a new or existing user. Below is the configuration profile.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict> <key>PayloadContent</key> <array> <dict> <key>PayloadContent</key> <dict> <key>com.apple.Terminal</key> <dict> <key>Forced</key> <array> <dict> <key>mcx_preference_settings</key> <dict> <key>SecureKeyboardEntry</key> <true/> </dict> </dict> </array> </dict> </dict> <key>PayloadEnabled</key> <true/> <key>PayloadIdentifier</key> <string>MCXToProfile.6aa7bd5a-89fe-4daa-827e-568b76a06b33.alacarte.customsettings.1cf380e5-afc9-47d5-9bff-cab47cea785a</string> <key>PayloadType</key> <string>com.apple.ManagedClient.preferences</string> <key>PayloadUUID</key> <string>1cf380e5-afc9-47d5-9bff-cab47cea785a</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </array> <key>PayloadDescription</key> <string>Included custom settings:
com.apple.Terminal

Git revision: a0e04c60fc</string> <key>PayloadDisplayName</key> <string>MCXToProfile: com.apple.Terminal</string> <key>PayloadIdentifier</key> <string>TerminalPreferences</string> <key>PayloadOrganization</key> <string></string> <key>PayloadRemovalDisallowed</key> <true/> <key>PayloadScope</key> <string>System</string> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>6aa7bd5a-89fe-4daa-827e-568b76a06b33</string> <key>PayloadVersion</key> <integer>1</integer>
</dict>
</plist>

[davidi4]

This plist works in Catalina, using the new Application & Custom Settings payload.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>SecureKeyboardEntry</key>
    <true/>
</dict>
</plist>

[boberito]

What use is this key now a days? Serious question. Is this even useful? Is it a sort of waste of a setting.

[Taylor_Armstron]

Why, @boberito ? Even if just from the standpoint of aligning with CIS, seems useful to me. (easier to align on items like this than to do the paperwork explaining why you deviated).

[Chris_p]

You could also create a user space launch agent that then calls your script at user login, so that it runs in user space. This way the end user can change the setting if they need.

[boberito]

The way is....maybe CIS should remove it. If it's shown it's useless and pointless it can be brought up to remove it.

[bradtchapman]

Since Apple implemented "Input Monitoring" as a TCC control, Secure Keyboard Entry seems like it's not needed as much because apps can no longer blindly read your keystrokes unless you grant them permission.  

There's a lot of the CIS benchmarks that should be removed or overhauled.  For instance, 'Disable Bluetooth' — LOL sure, only if you work in an air-gapped environment and everything's hardwired.  Nearly every company in the world would file an exception for that.

'Enable Firewall Stealth Mode.'  Can't be enabled if Firewall is not also enabled, and there are many security products that already mitigate the need to enable the macOS firewall.   The vendors in the security space are far ahead of the auditors and regulators.

I could go on and on.

[boberito]

I've changed my tune on Secure Keyboard Entry since this post. I actually do believe there are good reasons to have it. 

While I 100% agree there's TCC now which would prevent a lot of things. This helps prevent applications like TextExpander that you've given permission to from listening in on your keyboard strokes on the Terminal. This also doesn't allow other applications to secretly steal the focus. You can see how Terminal stays the focus for example when you do "open ~/". This will open your home directory in the Finder. When the setting is set, it'll be behind the Terminal. When the setting is off it pops up and takes focus. 

The rule in CIS isn't disable bluetooth, it WAS disable if nothing is paired or connected. But it's been removed in recent macOS Benchmarks. 

I think I'd much rather trust the built in macOS firewall than one from a random security vendor that's now running an agent and system extension on your system. I'm sure the 3rd party firewall offers more features, but there's nothing wrong with the application layer firewall in macOS. If you're checking a box for stealth mode, you're most likely checking a box for the firewall as well.