Danny Rosseau / file-canary · GitLab
gitlab.com
GitLab.com

I wrote a dead simple file canary tool that will install an eBPF program that drops all outgoing packets if a canary is touched. I wrote this in response to the current trend of supply chain attacks that try to harvest credentials

  • IanTwenty@piefed.socialEnglish
    51·
    2 days ago

    Thanks to these attacks I think creds got to all move to physical security keys so there’s nothing to (digitally) steal any more.This tool is a good idea for the short term.

    • Flyswat@lemmy.dbzer0.com
      1·
      13 hours ago

      Yes using TPM protected TSS2 keys would tie them to your actual machine since only that TPM can internally decrypt them and use them without then being accessible outside. The TPM could be a discrete chip or a software/virtual one.

      For instance OpenSSL has an engine/provider for tpm2-tss however I think the software using the keys needs to be engine-aware.

    • lemmyuser@programming.devOP
      6·
      2 days ago

      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

      • IanTwenty@piefed.socialEnglish
        2·
        17 hours ago

        I think the desktops need to better protect users’ secrets by accepting rogue user processes are part of the threat model now. There are lots of mechanism to lock known future user processes into a protected area (containers, chroot, etc), but none to lock existing and future unknown user processes out of a protected area.

        Your idea of a yubikey access protected file area makes a lot of sense and I don’t think it exists yet. Then a user could throw their existing ssh keys in there and immediately get physical protection on them.

        It would need to be carefully controlled. Something like gocryptfs on FUSE as you suggest but with a stronger threat model layered on top as theirs is short: https://nuetzlich.net/gocryptfs/threat_model/