1. 14
  1. 1

    Something interesting: the debug-me author has included gpg tooling in this, so presumably understands the value of keys, but there seems to be absolutely nothing to stop them just cat ~/.ssh/id_rsa etc, to generally steal anything.

    While the signed-logs bit might help drive this abusive user away, it doesn’t actually prevent the action from occurring.

    1. 3

      debug-me’s strategy seems to be aimed at forgoing black-/whitelisting commands, by having a binary choice of trusting someone with everything or not (I may be wrong, there might be more granular access rights).

      If the developer did do something bad, you’d have proof that they cannot be trusted, which you can share with the world. Knowing that is the case will keep most developers honest.


      When demonstrating “can I view your database?” in the first video, the author wants to believe the best in people, and trusting them with your own computer once they are proven to be who they say they are. Your example seems to be addressed in the long-term, by moving the target to attacking the GPG identity/communication itself.

      I’m just curious, do you have any ideas or workflows that would stop the attack you mention?

      If the user needs help debugging something real, the jail approach seems out of scope unless ‘everything’ is jailed and that mechanism has its own way of sharing sessions. My personal experience is mostly TeamViewer which, just as debug-me, relies on synchronous manual monitoring by the host (i.e. the amount of trust is high).