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.
>> 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.