On Fri, 8 Feb 2019 at 02:37, Russ Allbery <ea...@eyrie.org> wrote:
> Derek Martin <c...@pizzashack.org> writes:
>
> It may also be worth noting that this wouldn't have blocked the recent
> security vulnerability around SSH config handling, where scp on the server
> side could be tricked into reading an uploaded SSH config file that
> specifies an uploaded shared object to dynamically load and execute as a
> PKCS#11 provider. :(
>
Yes and no. If you were intentionally allowing scp in client mode to make
outgoing connections from your server then you couldn't use libcallfilt
with it in its current form anyway, as you'd have to allow scp to exec ssh
to function. However if you only wanted to allow scp so that people can scp
things to and from your server then libcallfilt would prevent it from
exec-ing ssh even if you failed at restricting the options to enforce
server mode.
Even my idea presented earlier on the list of forcing a specific rsync
> command line on the server side (which could then be implemented with SSH
> force-command) *still* is exploitable if the home directory of the user is
> writable because of rsync popt support loading ~/.popt.
Writable $HOME seems pretty risky in general for command restriction, I
suspect the ~/.popt thing is just one of many.
sftp is probably closer to the "correct" solution to this problem. The
> Subsystem facility that it uses avoids passing things through shells, and
> it can be used with ChrootDirectory to enforce a file namespace. And it
> won't have "features" like loading popt configuration files.
>
A restricted view of the filesystem is certainly good, if not using a
command built into ssh it would make sense to nsjail/firejail/bubblewrap
the executed command to get seccomp filters and filesystem limiting.
If you really want the rsync protocol then a forced command of "${things
such as nsjail and libcallfilt go here} rsync --server --daemon --config
/etc/some-rsyncd.conf ." is probably about as solid as you can get it:
rsync in daemon mode is designed to interact with an untrusted user, and
you get to set which parts of the filesystem are readable and writable in
/etc/some-rsyncd.conf.
You do have to adapt the rsync client command though, to work in terms of
modules defined in your rsyncd.conf rather than file paths:
rsync -av -e ssh /my/thing u...@rsync-server.example.com::backups/
_______________________________________________
rssh-discuss mailing list
rssh-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rssh-discuss
