Use macOS Keychain?

[juanjonol]

Usually, using the Keychain is the right call. But with Unlock, I'm not convinced. Am I missing something?

What Unlock-Redux does

Unlock-Redux simply creates a JSON file and stores all the passwords (with other attributes) in it. This file is only readable and writable by root (something that is checked each time the file is used).

Pros of using the Keychain

• A more standard location for passwords (also solves Better place for the passwords #3).
• Maybe it makes the program simpler? (no more JSON parsing needed).
• The passwords are encrypted at rest. This would be important to avoid them being read from a different OS (extracting the disk and reading from a different computer, for example), but the point of Unlock is to be used in a FileVault-encrypted system, which renders this point moot.
  • What's more, Unlocks uses the System Keychain, and the System Keychain's password is stored in plaintext, so it's is the same as if the System Keychain was not encrypted at all. See this comment for more info.

Cons of using the Keychain

• Obviously, I have to spent time to implement its support.
• Is more vulnerable? Is seems difficult that macOS has a bug that could let an attacker read a file owned by root but not let them read the keychain. However, it would be far less farfetched that macOS has a bug that could let an attacker read the keychain. In fact, this has happened recently.
• It's looks like High Sierra has a bug that makes the keychain unusable at startup.
• Using the System Keychain gives a false sense of security: it's easy to think that the System Keychain is encrypted and protected by a password, but essentially it's only protected by root permissions. In contrast, Unlock-Redux is clear about it's security. See this comment for more info.

[tkoenig]

@juanjonol regarding the Pros: I'm not sure about this, does it have to be used in a FileVault encrypted system?

We're having a scenario where we are using OS X as a server without FileVault encryption for the boot volume, since you could not boot or reboot a server without entering a password (direct access). Therefore we have the Data on an external drive which is encrypted.

If the password is stored on the (boot) disk in plain text, this could be easily exploited.

[juanjonol]

Hi!

It can be used without FileVault, but even in that case I still don't see any benefit from using the keychain: if the server can be started without a password, the keychain's password must be stored in plaintext on the boot disk, or you would have to manually unlock the keychain after each start. Am I missing something?

Also, although the passwords are stored in plaintext, they can only be read by root. Without FileVault, an attacker with physical access could extract the disk from the server and read all the passwords from another computer (root permissions are ignored across OSs), but this attack would also allow the attacker to read the keychain (like I said, the keychain's password must be stored in plaintext too) and a lot of other things (installing a rootkit, for example). So I don't see how this more easily exploitable than the keychain.

[juanjonol]

I guess that if someone needs:

1. A Mac that its manually unlocked (the keychain's password is not stored anywhere).
2. A Mac that doesn't use FileVault for its boot drive for some reason.
3. A threat model in which being able to read the boot drive from another computer or OS is a real risk.

Then there would be a good reason for using the keychain. But I cannot think of anyone with this requirements.

[tkoenig]

No, the keychain password must not be stored in plaintext somewhere: https://github.com/jridgewell/Unlock#is-my-data-really-secure

[juanjonol]

I have researched this, and I have found that the System Keychain's password is stored in /var/db/SystemKey in plaintext, readable by root only (just like Unlock-Redux's passwords). See this for more info.

So Unlock's README is not correct: the System Keychain is secure, but it isn't tied to it's computer.

Also, I see using the Keychain even more pointless now: for some reason, I assumed that Unlock used the User Keychain, which is unlocked at boot with the user's password (unless you make the system bootable without a password, like in your case), but Unlock using the System Keychain means that all Unlock's passwords are essentially in plaintext (encrypted data with the key next to them is for all purposes the same as plaintext data), protected only by root permissions, just like Unlock-Redux's passwords.

[galaxy4public]

In my BootUnlock project here on GitHub, I am using the system keychain. The access to the system keychain is managed by the extended attributes and by default DiskUtil helper tool has access there (this is the tool that pop-ups prompts for unencrypting all the encrypted volumes on the system once you login), so what I did is I copied the security tool under a different name (since security tool needed to access the system keychain), restricted access to it (so only the process that runs my unlock script could execute the binary), then signed it with a local key, and from that point on, I can specify which encrypted volume my my script can unlock at boot using the system keychain: https://github.com/openwall-com-au/BootUnlock/blob/bb60e80c44e2e6527f93fcd5e67907d4a7f941d4/files/update.sh#L86

[juanjonol]

Hi! I'm not sure what you're gaining from copying security tool?

[galaxy4public]

The script is using macOS keychain, but in order to decrypt the volumes in an unattended mode the entries are made readable to the copy of the security tool (the binary is self-signed on install). The reason why I could not use the system version is that it is executable by everyone on the system, hence it would mean that anybody could retrieve the credentials.

…

On Wed., 9 Oct. 2019, 18:33 juanjonol, ***@***.***> wrote: Hi! I'm not sure what you're gaining from copying security tool? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8?email_source=notifications&email_token=AB72A6UN2D6HNFNCXXEYO4DQNWCODA5CNFSM4EPWIEC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAW6CHY#issuecomment-539877663>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB72A6T6WT33W6275TCLYSLQNWCODANCNFSM4EPWIECQ> .