How to implement Terminal - Secure Keyboard Entry

alaiuppa
New Contributor

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?

1 ACCEPTED SOLUTION

mm2270
Legendary Contributor II

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

View solution in original post

8 REPLIES 8

mm2270
Legendary Contributor II

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

View solution in original post

alaiuppa
New Contributor

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

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
New Contributor III

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
Valued Contributor

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
Valued Contributor

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
New Contributor

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
Valued Contributor

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.