rsync - Aug 2009 - DO NOT REPLY [Bug 1890] TLS for rsync protocol

https://bugzilla.samba.org/show_bug.cgi?id=1890


devzero at web.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |devzero at web.de




------- Comment #3 from devzero at web.de  2009-08-07 05:11 CST -------
wouldn`t it be better to give up on that effort and recommend stunnel for
ssl/tls with rsync ?

http://www.stunnel.org/examples/rsync_mike.html


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=1890





------- Comment #4 from marineam at osuosl.org  2009-08-07 14:52 CST -------
stunnel is usable but it is rather annoying to use for something like pulling
backups over rsync using something like dirvish. In that case every host being
backed up will have rsync and stunnel daemons running which is simple, but then
the backup job has to wrap the rsync command with extra goo to start and stop a
stunnel client. So doable but if rsync just supported tls everything would be
much friendlier. 


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=1890





------- Comment #5 from paul at debian.org  2009-08-08 06:00 CST -------
Simply using rsync over ssh should be enough encryption for most purposes,
IMHO.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=1890





------- Comment #6 from devzero at web.de  2009-08-08 06:44 CST -------
when using rsync over ssh, you give a remote user interactive shell access.
shell access is not needed for that and may quite often impose a severe
security risk. (undermine firewall policies etc)

how do you prevent that ?

there may be some way to use a restricted shell like scponly, but all such
solutions are just an ugly hack, as they are adressing an architectural
problem.

furthermore , you cannot use ssh for encryption when running rsync in daemon
mode. 

so, the demand for "sending/receiving data trough an encrypted socket
connection" is valid, and thus the request for tls here.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=1890





------- Comment #7 from jamie at shareable.org  2009-08-08 18:16 CST -------
It's easy to tell an ssh server to restrict what commands can be run.
For example, with OpenSSH it goes in $HOME/.ssh/authorized_keys.
That's what I do for making backups: I allow an ssh root login, restricted
just to the rsync command needed for making a backup.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=1890





------- Comment #8 from carson at taltos.org  2009-08-09 00:18 CST -------
authorized_keys command limits sadly only work for public key auth. TLS support
in rsync would be of significant value. Yes, there are hacky ways to work
around it today, but they all have significant issues in many circumstances.


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=1890





------- Comment #9 from devzero at web.de  2009-08-09 05:33 CST
-------
> It's easy to tell an ssh server to restrict what commands can be run.
is that really secure? i think, no.

found this one on the scponly pages:

SECURITY PROBLEM 2, reported by Pekka Pessi

If ANY the following conditions are true, administrators using scponly-4.1 or
older may be at risk of remote scponly users circumventing the restricted shell
and executing arbitrary programs. There is no privilege escalation and this
vulnerability is post-authentication.

    * scp compatibility is enabled
    * rsync compatibility is enabled 

Exploit:

To exploit this vulnerability, a remote scponly user could:

    * construct a malicious command line argument to either the rsync or scp.
Athough scponly does check for arguments that allow the user to specify a
program to run, it does not use getopt() style processing to locate these
potentially malicious arguments. For example, the potentially malicious scp
argument "-S program" would be detected but by combining it with the
benevolent
"-v" (yielding "-vS program") would not. 

Fix:

The new release of scponly-4.2 has:

    * getopt to process the arguments to scp and rsync.
    * no support rsync or scp by default. henceforth, the recommended means to
use scponly is via sftp
    * other fixes and features
    * fix for openbsd ldd in setup_chroot
    * sftp-logging compatibility patch
    * fix for autoconf AC_INIT macro
    * patch for command line args to setup_chroot invocation
    * patches to fix passw 


here is some more interesting article which shows, that this is sorta hackerish
method:

http://www.oreillynet.com/linux/blog/2006/05/restricting_rsync_over_ssh.html


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

https://bugzilla.samba.org/show_bug.cgi?id=1890





------- Comment #10 from jamie at shareable.org  2009-08-09 05:54 CST
-------
> > It's easy to tell an ssh server to restrict what commands can be
run.
> is that really secure? i think, no.
Yes, assuming you trust rsync itself.

For backups, don't use scponly, the grossly insecure script at the end of
the
oreillynet link, or anything else which gives the client much flexibility. 
Limit the ssh environment, and in the fixed command script, verify the command
it's asked to run is exactly the one it's allowed to run, no dubious
"parsing".


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.