Revisit handling of wrapped keys/master passwords about kbs2 HOT 4 CLOSED

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

from kbs2.

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

from kbs2.

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.

from kbs2.

#103.

from kbs2.