<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 9, 2017 at 6:43 AM, Daniel Roethlisberger <span dir="ltr"><<a href="mailto:daniel@roe.ch" target="_blank">daniel@roe.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Specifically, I am not interested in manually approving agent<br>
requests. The ratio of hassle to mitigated risk is unreasonable<br>
in my opinion. It addresses a narrow category of attacks while<br>
not helping against other attacks with similar prerequisites and<br>
risk (e.g. injecting commands into TTYs of SSH sessions from the<br>
compromised system, or replacing a legit auth challenge on the<br>
compromised server as it is being handed to the client machine's<br>
agent where it will be approved by the user). So unless the<br>
confirmations can be easily removed by configuration or patching,<br>
I won't be overly excited about this.<br></blockquote><div><br></div><div>Thanks for your feedback, Daniel. I think if you try it, you will be pleasantly surprised.</div><div><br></div><div>On the issue of "manually approving agent requests" -- you don't have to. The local agent gets to see and approve each request, but the user can "allow forever" and doesn't need to approve each request manually.</div><div><br></div><div><div>Re: "additional network and firewall considerations," Guardian Agent just runs over autossh. If you can SSH to the intermediary, you can run Guardian Agent.</div></div><div><br></div><div>On the "other attacks with similar prerequisites" -- if I understand you, Guardian Agent already prevents these attacks. The "legit auth challenge" is bound to the triple of { intermediary machine, command, server }, so it's not possible to "replace" a legit auth challenge and use the user's credentials to execute a different command (or on a different server, or from a different intermediary) than what was requested. (The way that Guardian Agent works is that the local agent actually issues the command to the remote server before handing over the session to the intermediary.) So while a compromised intermediary machine can *ask* to execute an evil command, the agent will know about it and it won't match some prior "allow" rule in the local configuration.</div><div><br></div><div>(To be clear, this works best for commands like 'git fetch-pack' to a particular repository or something like that, where the command is not going to allow arbitrary follow-on commands to be executed. If the user wants to execute a shell or some other interactive session, then yes, this doesn't prevent a malicious intermediary from later inserting arbitrary input into the session. Probably the best thing in that case, if you really don't trust the intermediary, would be to just to use the intermediary to ferry ciphertext bytes and not to let it see the plaintext at all. But even in that case, at least Guardian Agent still lets you lock down which intermediaries can connect to which remote servers.)</div><div><br></div><div>-Keith</div></div></div></div>