[scponly] unable to rsync with rsync-enabled scponlyc ...

[Paul Hyder]

user wrote:
> Hello,
> 
> On Thu, 27 Oct 2005, Hideyuki KURASHINA wrote:
> 
> 
>>>I have installed scponly on a FreeBSD 5.4 system, using the compile time
>>>options:
>>>
>>>WITH_SCPONLY_CHROOT="yes" WITH_SCPONLY_RSYNC="yes"
>>
>>Thanks for using FreeBSD port.
>>
>>
>>>It has been working fine for me - I have successfully scp'd documents to
>>>my target users on the host that have the scponlyc shell specified as
>>>their shell.  I have tested the chroot cage, and that works as well.
>>>
>>>I cannot, however, rsync as those user.
>>>
>>>When I try to rsync files to that user at host, I get this error:
>>>
>>>rsync: connection unexpectedly closed (0 bytes received so far) [sender]
>>>rsync error: error in rsync protocol data stream (code 12) at io.c(365)
>>># 
>>># rsync -avz -e ssh hepper good at 192.168.0.4:/good 
>>
>>               ^^^^^^
>>
>>>Password:
>>>rsync: connection unexpectedly closed (0 bytes received so far) [sender]
>>>rsync error: error in rsync protocol data stream (code 12) at io.c(365)
>>
>>I think this is just a design, but not a bug.
>>
>>  rssh and scponly arbitrary command execution
>>    http://www.securityfocus.com/archive/1/383046
>>
>>found by Jason Wies will show the answer (This vulnerability was fixed
>>in scponly v4.0).
>>
>>How about using environmental variable RSYNC_RSH rather than '-e ssh' ?
> 
> 
> 
> I was under the impression that this problem had been solved, and what you
> are describing is not a very good solution (although, yes, it would work).
> 
> If you read the security advisory, you see that the author suggests that
> there be a whitelist of allowable executable actions to pass on to
> programs like rsync.
> 
> Can someone look at my theory here and tell me if it is correct ?  My
> theory is that you would, as the administrator, make sure there is only
> one 'ssh' binary on your system, and you would then whitelist "ssh" as a
> "good" program for scponly-allowed-programs to pass to.  Which would then
> allow me to use '-e ssh' as an argument, as I do above.
> 
> -----
> 
> There are two things that confuse me, though - first, I understand the
> advisory, and I understand the security problem, but I don't understand
> why '-e ssh' falls into that category, since ssh is a program that scponly
> runs to begin with.  The advisory advises a configurable "executable
> whitelist", which is all fine and good - I just don't understand how ssh
> is not already on a more basic, internal whitelist ... since scponly
> supports ssh to begin with.  Comments ?
> 
> Second, can you further explain the fix you are suggesting to me - you are
> suggesting I set an env variable on the _rsync server_ that tells rsync to
> assume that all incoming rsync connections are over ssh, and that way the
> rsync client does not need any -e option on his command line ?  Is my
> understanding correct ?
> 
> thanks a lot.

I believe that the reasoning in effect is that ssh is the normal rsync
remote shell and hence it isn't necessary to specify it explicitly.
Scponly, using this logic, can then reject all rsync commands that use
"-e".

Yes it is possible for rsync to be configured with other defaults but
that isn't common and in a chrooted scponly environment not likely to
work.

The more important question probably is "Have you found a modern
implementation of rsync that doesn't use ssh as the default remote
shell?"  (OR Why did you need to specify the remote shell?)
	Paul Hyder
	NOAA Earth System Research Laboratory, Global Systems Division
	Boulder, CO