iconv and daemon mode

[Matt McCutchen]

On Sat, 2008-02-09 at 17:41 -0500, Matt McCutchen wrote:
> Instead,
> let's recommend daemon administrators to copy the necessary encoding
> helper libraries into the module and daemon-exclude them.

Ouch, this brings up a serious problem.  Any writable chrooted module
that accepts --iconv has to protect the locations where the C library
looks for iconv helper libraries really well (whether or not the
libraries are actually present!), because a client who can create/modify
libraries in these locations can cause arbitrary code to be run in the
daemon process.  The chroot will stop an injected daemon process from
doing certain kinds of damage, but we still absolutely don't want
clients circumventing policies that the daemon administrator has put in
place.  (Here is a rare example where chroot actually *decreases*
security.)

IMO, we can't afford for rsync 3.0.0 daemons to be insecure by default,
so they should not allow --iconv for writable chrooted modules.  A
daemon administrator who has set up appropriate security measures
(either file permissions, or daemon excludes + the accompanying option
refusals recommended in the recent advisory) should be able to override
this.  If the --iconv refusal can be incorporated compatibly into the
existing "refuse options" parameter, great; otherwise let's have a
separate daemon parameter called "allow iconv" that defaults to "read
only || !(use chroot)".

In general, we need to be more careful about what C library features
chrooted daemons use.  Does anyone know if loading of untrusted time
zone files is a risk?

BTW, I found this previous mention of the conflict between chroot and
iconv in the archives, but the discussion never went anywhere:

http://lists.samba.org/archive/rsync/2006-October/016627.html

I guess I must not have seen that message at the time because I was
bogged down with college applications.  :(

Matt