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

[Robert Hoffmann]

Hi Joe,

Thank you for this great answer - I think it totally justifies NOT adding the suggested option. 

1) chmod go-rw pub/priv

You are right; this is exactly the solution I was looking for!  I plan to use hidden directories within pub/priv that have names of some 80 random chars length. So by repeated remote attempts a curious user wouldn't get very far.  Of course a local script might be able to map this - as you pointed out, but...

2) Local scripts to map out the directories - This would be the worst case scenario, right? Wouldn't it mean that scponly or ssh/scp were breached? 

3) SFTP. To be honest, I didn't spot that SFTP is by default ON+guessed
Well then, since you killed my original suggestion ...may I suggest at least an unequivocal "--disable-sftp-compat" option ;-)

Thanks again and best wishes,

Robert

p.s. For completeness. I AM using the chroot version of scponly. But I just don't fancy the idea of maintaining potentially dozens of user accounts - all basically for the same purpose. Especially, since the clients accessing this ONE account are trust worthy (in theory), and each configurable/traceable with it's own public key. 



On Jan 21, 2010, at 12:22 AM, wbr oblyr wrote:

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