Yeah it was a useful approach, "disprove me with code"
>> Don't forget to disable sftp in your sshd_config
>Doing `strace -fp $(pgrep sshd)` then `sftp userfoo@localhost` in another terminal, I see: [...]
>execve("/tmp/custom-shell.sh", ["custom-shell.sh", "-c", "/usr/lib/ssh/sftp-server"]
If your sshd_config had "Subsystem sftp internal-sftp" as a shipped default, then I don't think it would have gone through the user's shell. Not a major issue, but there are just so many little points to be certain are locked down
>I'd love to see a `ssh/sftp userfoo@localhost` call that does something other than call cmd_foo, cmd_bar, or erring out.
The reference to LD_PRELOAD was to hint at that (since if the attacker can get a binary on the system -- e.g. in a git repo or config file) they could change what functions bash is invoking... I'm not a wiley enough attacker, but I bet if you put something valuable behind it and put out a public challenge you'd be impressed with the opensshd vulnerabilities and other interesting features of ssh/tty/environment variables.
As you probably guessed, my comment was just listing a few of the things (today) that you're playing whack-a-mole with when it comes to making sure everything is secure. I think your "disprove me with code" approach is a great basis for a discussion.
Writing their own 'ssh server and shell' program is a different set of tradeoffs vs trying to fully lock down programs that are intended to be general-purpose... to be perfectly honest I don't think I'd want to be involved in either route, the stakes are stressfully high... but there sure is a lot less code to audit and test in writing your own ssh+shell than there is trying to secure and keep up-to-date sshd, pam, bash, etc. (especially since they'll be adding features that you explicitly do not want for your purposes)
Yeah, regarding whack-a-mole, I thought that wouldn't be necessary. I mistakenly believed:
>> As far as I understand, SSH's security of what a user can do is completely based on what the shell permits the user to do.
I was mistaken in believing that sshd was designed with the user being limited to their specific shell as their sole system interface (as their only way to get the system to do things) as a core design principle. With that sort of funnel, I thought a custom shell would suffice.
> If your sshd_config had "Subsystem sftp internal-sftp" as a shipped default, then I don't think it would have gone through the user's shell.
It's curious how much you can do on a secure "shell" server without involving shells at all.
You know, what's particularly interesting is that strace shows sshd does `custom-shell.sh -c /usr/lib/ssh/sftp-server` instead of `/usr/lib/ssh/sftp-server` directly. That feels like it has no other purpose than to adhere to the principle I believed it was following, but it doesn't apply it for everything. I think it should be possible wrap stuff like `-L`, `-R`, `-D`, `-J` et al. in their own shell calls to another executable, but they don't... Wonder what's the story there.
> The reference to LD_PRELOAD was to hint at that (since if the attacker can get a binary on the system -- e.g. in a git repo or config file) they could change what functions bash is invoking
I had mentioned that the client's environment is not accepted by sshd by default, so I did address this point in my previous comment. Maybe what you're getting at here is that the shell itself may allow modifying the environment through its own logic? But you're still going to have that issue regardless of whether you use sshd or a custom integrated
ssh server.
> Writing their own 'ssh server and shell' program is a different set of tradeoffs vs trying to fully lock down programs that are intended to be general-purpose
Indeed. If the hassle to lock-down is large enough, it can be better to opt for simpler, more easily verifiable software. Tradeoffs aplenty, and one such is that you may end up adopting less mature software, by way of the chosen dependencies and your own code, however that server is implemented. That can be worth it.
>> Don't forget to disable sftp in your sshd_config >Doing `strace -fp $(pgrep sshd)` then `sftp userfoo@localhost` in another terminal, I see: [...] >execve("/tmp/custom-shell.sh", ["custom-shell.sh", "-c", "/usr/lib/ssh/sftp-server"]
If your sshd_config had "Subsystem sftp internal-sftp" as a shipped default, then I don't think it would have gone through the user's shell. Not a major issue, but there are just so many little points to be certain are locked down
>I'd love to see a `ssh/sftp userfoo@localhost` call that does something other than call cmd_foo, cmd_bar, or erring out.
The reference to LD_PRELOAD was to hint at that (since if the attacker can get a binary on the system -- e.g. in a git repo or config file) they could change what functions bash is invoking... I'm not a wiley enough attacker, but I bet if you put something valuable behind it and put out a public challenge you'd be impressed with the opensshd vulnerabilities and other interesting features of ssh/tty/environment variables.
As you probably guessed, my comment was just listing a few of the things (today) that you're playing whack-a-mole with when it comes to making sure everything is secure. I think your "disprove me with code" approach is a great basis for a discussion.
Writing their own 'ssh server and shell' program is a different set of tradeoffs vs trying to fully lock down programs that are intended to be general-purpose... to be perfectly honest I don't think I'd want to be involved in either route, the stakes are stressfully high... but there sure is a lot less code to audit and test in writing your own ssh+shell than there is trying to secure and keep up-to-date sshd, pam, bash, etc. (especially since they'll be adding features that you explicitly do not want for your purposes)