Revisit handling of wrapped keys/master passwords

[woodruffw]

This needs more thought before I or someone else goes and does it, but:

• The current master password approach is slightly ugly: it uses a not-very-well-specified POSIX API (named SHM objects) and requires additional hacks for different OSes.

• Most modern desktop environments already provide an integrated keychain, and some (like macOS) integrate that keychain tightly into hardened hardware. This makes it an ideal place to store a master password.

• There are a few Rust crates for managing system keychains/keyrings:

  • https://github.com/hwchen/keyring-rs
  • Some stuff here: https://crates.io/keywords/keychain

• We should still fall back on the current approach when we fail to detect a suitable keychain to interact with, or if the user specifically requests the current approach.

[woodruffw]

Alternative idea: use an agent-style architecture:

• kbs2 --agent asks for the master password and runs in the background with the unwrapped key in memory
• Subsequent kbs2 invocations check for a Unix domain socket based in part on the keyfile name, and use that to temporarily grab the unwrapped key

Pros:

• Lots of decent reference material (ssh-agent)
• Same threat model as the current approach (an attacker with the same or greater permissions as the current user can steal the wrapped key, but an offline attacker can't)
• Probably simpler than the current SHM mess
• Actually ends the "session" on user logout, which is more intuitive than the current behavior

Cons:

• Requires a background process
• Requires messing with Unix domain sockets in Rust

[woodruffw]

Ratcheting down the security of an agent-style approach: kbs2 --agent would be run from the same underlying executable as any subsequent kbs2 calls, so the executable path could be a some authenticity check for the client. That doesn't stop someone from replacing the kbs2 executable with something malicious, though.

Braindump:

• Linux supports SO_PEERCRED for getting the PID of a Unix socket client
• macOS appears to support getpeereid(3) and LOCAL_PEERCRED for the same purpose
  • Edit: getpeerid/LOCAL_PEERCRED only does uid and gid for some reason. Annoying. Apparently LOCAL_PEERPID works, but is undocumented.

Then, from the client PID:

• Linux: readlink on /proc/{PID}/exe to get the original executable path
• macOS: Use proc_pidpath or something else from libproc to get the executable path
  • https://docs.rs/libproc/0.9.1/libproc/index.html

[woodruffw]

More braindump:

• kbs2 --agent does a checksum of its own executable on startup
  • https://doc.rust-lang.org/std/env/fn.current_exe.html
• After resolving the executable path of the client requesting the unwrapped key, do a checksum of that path's contents
• If the checksums match, allow the connection

Downside:

• Different versions of kbs2 running on the same host won't be able to talk to the same agent.

[woodruffw]

#103.