3 ms·
In the screencap - whoami on the left shows 'stephen' and the shell on the right also shows 'stephen', so ultimately it looks like 'stephen' ends up approving h
by eps 8y ago
In the screencap - whoami on the left shows 'stephen' and the shell on the right also shows 'stephen', so ultimately it looks like 'stephen' ends up approving his own sudo request, which defeats the whole purpose. I assume that's not possible, but perhaps clarify this part?
- stouset 8y agoGood catch. :) It might be hard to read in the gif, but at Square, we actually allow users to approve their own sessions. When this happens, it's logged in such a way that an oncall infosec person is paged immediately. Users know not to do this except in case of emergency; the whole point is to have an in-case-of-fire-break-glass escape hatch during, e.g., a critical outage in the middle of the night. The logic for this[1] is currently in the approval script (and in the sample one provided, it does deny access). However, I intend to make this a responsibility of the plugin itself[2] shortly, where you can toggle between denying and logging. Also, it's pretty easy to take the output from `socat`, pipe it to GPG, and archive the session afterward, for forensic purposes. We plan to do this latter part as well (possibly through the approval script, possibly as a second plugin). [1]: https://github.com/square/sudo_pair/blob/master/sample/bin/sudo_approve#L75 https://github.com/square/sudo_pair/blob/master/sample/bin/s... [2]: https://github.com/square/sudo_pair/blob/master/sudo_pair/src/lib.rs#L133 https://github.com/square/sudo_pair/blob/master/sudo_pair/sr...