the reason i use this (and just a container with -v $HOME:$HOME before) is to get an environment with all the command line tools i'm familiar with from debian, instead of using something like homebrew. in general, i mostly trust these with access to my home directory. a bonus is that i can throw it away and rebuild it easily if i need to.
i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.
i used to slip mine in a manilla envelope whenever i needed to take it home from the office and i hadn't brought my backpack with me. our stationary cupboard was well stocked with these!
> You can mitigate this by including PCRs that sign the kernel and initrd
nope! the trick the article is describing works even if the kernel and initrd is measured. it uses the same kernel, initrd, and command line.
the reason this trick works is that initrds usually fall back to password unlock if the key from the tpm doesn't work. so the hack replaces the encrypted volume, not the kernel, with a compromised one. that is:
1. (temporarily) replace encrypted volume with our own, encrypted with a known password.
2. boot the device.
3. the automated tpm unlock fails, prompting for a password.
4. type in our password. now we're in, using the original kernel and initrd, but it's our special filesystem, not the one we're trying to decrypt.
5. ask the tpm again for the key. since we're still using the original kernel, initrd, and command line, we should now get the key to unlock the original encrypted volume.
the way to fix this is to somehow also measure encrypted volume itself. the article points to suggestions of deriving a value from the encryption key.
I developed it mainly on Firefox on macOS. I'd love to figure out why it didn't work for you. Do you get anything on about:webrtc while trying to connect?
Someone mentioned the command line client. One can also build and serve the html/js/wasm from anywhere and it should still work, even with the same signalling server. It has pretty lax CORS for this reason.
This uses STUN servers to help it poke through NATs. (That's what I mean by "WebRTC's NAT traversal tricks")
There's no TURN server set for this, but it shouldn't be hard to add one. There are NATs where you'd need one to relay all the traffic, but these seem to be relatively rare nowadays. If anyone has any actual statistics on these I'd appreciate it!
Codes are intentionally single use, to limit the bruteforce vector. And only two peers can connect any given time currently. It would be interesting to figure out how to make it work with more than 2 peers!
Making usable interfaces that work in a single directions is really hard. Making them work in both is much much harder.
The bugs might be funny, but I have great respect for the programmers trying to make their applications more accessible, be it for right-to-left languages or otherwise.
i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.