I'm hesitant to share my list :)

I'd consider looking at recent attacks by TeamPCP and the recent AUR compromise for inspiration. Some obvious targets are fake SSH keys, cloud provider credentials that you don't use, package manager credentials that you don't use, etc. Also things that allow a configuration and accept a default value you can place a canary at the default value and configure for a different path.

I agree, for serious secrets you should have something physical involved.

I spent a bit of time exploring some mechanism to encrypt files on disk and require a yubikey press to decrypt them transparently for the process requesting access, but I didn't really come up with a solution I liked. The idea there would be you're prompted "/usr/bin/safe wants to access secret.key, but it is marked as sensitive, decrypt and allow?". The notification part would be easy with fanotify but it wasn't entirely clear to me the best way to perform the decryption. I think storing the secret on a FUSE file system could work? Things like https://github.com/rfjakob/gocryptfs come to mind

Right it's just for things you don't use but a credential harvester would find interesting.

I've been working a lot on containing the blast radius with some careful LXC usage, but this was a quick way to get some real value without a ton of thought.

There is a very high chance there are files you will never use that a credential harvester would be interested in. For example some look for certain wallets that I definitely don't have, so I create a canary file for that. You can also add $HOME/.ssh/id_rsa and $HOME/.ssh/id_ed25519 and then use nonstandard key names for your typical key usage etc.

I've been running this for a week now with no lost connections yet :)

Yes you can -send-sigstop to SIGSTOP the process and then do whatever you'd like on your -on-touched-exe such as attach via ptrace, dump all memory, etc. My current one will send a notification and dump the memory of the offending process.

Definitely pay attention to the warning about running this on a server. With a KVM attached in a home lab you should be able to easily recover I guess. I think you could also set yourself up a little UDP service to SIGUSR1 the daemon since incoming packets are not dropped, but I haven't tested that.

[Note: intelligent malware can handle the SIGSTOP fairly easily. You could try to move the process to a new cgroup and then freeze the cgroup, as well, but there is a lot to consider here obviously]