[scponly] Suggestion for new option: disable-recursion - And why this could be useful

wbr oblyr joe at sublimation.org
Wed Jan 20 18:22:44 EST 2010


Hi Robert,

Thanks for the feedback - I'm glad to hear you've got it working the
way you like.

There are a couple sngas with the suggestion, however.  I want to
point them out to be sure that you've taken them into account.  First,
in the case where sftp is also supported, there is no command-line
option to disable recursion via sftp-server.  So, if you're using this
technique, be sure to disable sftp-server when you build scponly.

The second, and bigger problem, is that disabling recursion is only
effective against an idle, curious, "clicking around" attacker.  A
more serious attacker could automate a script to walk through and make
a map of the entire directory tree without much difficulty.  I'd be
reluctant to provide the option as a security enhancement and end up
giving a false sense of security to those who don't have the time or
interest to really investigate the weaknesses of the suggestion.

The third snag is that it's possible to craft a directory structure
which prevents recursive traversal by crafting directories with
"execute-only" permissions (no read or write permissions),
accomplishing your goal without a patch:

# create a directory tree with an execute-only directory called "priv"
[joe at phantom tmp]$ mkdir -p pub/priv/hidden
[joe at phantom tmp]$ touch pub/priv/hidden/secretfile
[joe at phantom tmp]$ sudo chown root:wheel pub/priv
# remove all but execute privileges
[joe at phantom tmp]$ sudo chmod go-rw pub/priv


[joe at phantom tmp]$ ls -ltar pub
total 12
drwx--x--x 3 root wheel 4096 Jan 20 18:07 priv
drwxrwxrwx 3 root root  4096 Jan 20 18:07 ..
drwxr-xr-x 3 joe  wheel 4096 Jan 20 18:07 .
[joe at phantom tmp]$ ls -ltar pub/priv
ls: cannot open directory pub/priv: Permission denied

# can only access the "hidden" subdir if you know its name
[joe at phantom tmp]$ ls -ltar pub/priv/hidden
total 8
drwx--x--x 3 root wheel 4096 Jan 20 18:07 ..
-rw-r--r-- 1 joe  wheel    0 Jan 20 18:08 secretfile
drwxr-xr-x 2 joe  wheel 4096 Jan 20 18:08 .
[joe at phantom tmp]$

I didn't paste the results, but a recursive copy command is also
unable to penetrate the execute-only directory, meaning only
specific-named directory access can reach "secretfile".

This may have been what you intended in the first place.  However,
this is still subject to brute-force attacks which are not
rate-limited on failed attempts.

If you haven't already, I'd suggest investigating the chroot feature
of scponly - which would allow you to jail each user name in its own
directory tree much more securely than secretly-named directories.

Still, I appreciate the discussion - let me know what you think.
joe

On Wed, Jan 20, 2010 at 7:49 AM, Robert Hoffmann
<hoffmann at cbio.mskcc.org> wrote:
> Hi,
>
> I would like to suggest a new option for configuration:
> --disable-recursion
>
> The objective would be to disable scp -r (and equivalent for other commands).
>
> Why could this be useful?
> I have setup ONE rootjail user account for scponly. Only clients with a qualified public key may scp to that account. All clients use the same account.
>
> Some data in that account is of interest to all clients, but there will also be folders with long random names, which only a subset of the clients knows about.
> This setup is supposed to prevent sneaking among clients. It is not intended to be top security separation, but I believe it could actually be quite efficient.
>
> For my personal use, I have patched scponly.c to add the 'bad' options, but I thought it could be of general interest or use.
>
> Btw, scponly rocks!
>
> Best wishes,
>
> Robert
>
>
>
> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly
>



More information about the scponly mailing list