The developer mode renewal script exposes the private ssh key to unintended users for a short time

[nagisa]

Describe the bug

When going to the Info > Automatic Developer Mode Renewal > Script section, the code reads as such:

dev-manager-desktop/src/app/info/renew-script/renew-script.sh

Lines 9 to 15 in 669387f

	PRIV_KEY_FILE="/tmp/webos_privkey_${DEVICE_NAME}"
	cat >"${PRIV_KEY_FILE}" <<END_OF_PRIVKEY
	{{keyContent}}
	END_OF_PRIVKEY
	chmod 600 "${PRIV_KEY_FILE}"

Observe that this script first writes the key to the usually world-readable+sticky-permissions /tmp/, and only then chmods the file to 0600 to restrict the access to it.

This is racy and it is quite possible that an external observer would be able to open the file before the permissions to it are changed.

Expected behavior

The script should instead utilize the umask mechanism to set a permissions mask before creating the secret key file, thus making it create the private key file with the correct permissions straight away.

An alternative method would be to create a directory within /tmp, set the 0700 permissions on it and only then create the file within that directory.

Screenshots

N/A

Additional context

• OS: N/A

[throwaway96]

What do you think about ddbc8f2? I'm not really set up to test it. Also, I'm not sure what platforms this script is supposed to run on and if mktemp is available on all of them.

[nagisa]

This looks good for me in context of linux at least. mktemp does exist on macs and as far as I know BSDs too. Ultimately if people are grabbing the script and integrating it into their systems, more likely than not they will know how to adjust it to work on their system in absence of mkdir, whereas if it works, but exposes secrets, it might go by unnoticed.

---

Yet another option would be to create and set up file before writing data to it:

touch file
chmod 0600 file
echo "$key" > file

but I'm partial to the mktemp variant personally.