On Mon, Feb 12, 2001 at 02:37:44PM -0500, Wrieth, Henry wrote:
> Regarding the secrets file:
> All hosts I distribute to are either internal or in some DMZ. In most Wall
> Street firms the internal network is deemed safe so, it is still ok to have
> clear passwords on the wire. We telnet everywhere. But it is deemed risky
> to have clear passwords on the filesystems. Local sys admins would have
> access to passwords which may be used across different domains. Shelves
> full of broken drives could be read, whatever, it is just not allowed.
> In situations where the network is insecure and the server is secure, I
> agree, it makes more sense to do it your way. All I am recommending is we
> add an alternative.
In that case why not use rsh?
Alternatively, if you want to use passwords maybe rexec is what you need.
Most Unix machines have an rexec server and an rexec(3) library call to
invoke it but not all systems have a command level tool to use it (Linux
does although I believe I heard it may be removed in the most recent
releases).
> Regarding chroot:
> It seems there is a big concern about giving up the default chroot nature of
> the child process. I think this is because chroot is being used by rsync to
> enforces module security rules as it does with regard to links. The
> conventional idea of chroot, as when you chroot a web or ftp server, is to
> protect the host from a rogue daemon. If a daemon were compromised by a
> hacker and that hacker has now assumed the username of the daemon, the
> hacker will only be able to see files up to the chroot directory and will
> only have access to executables in the chroot tree. This way, when a hacker
> becomes the server he will not be able to damage, say /etc or /usr and will
> not be able to execute rm if it is not in the chroot tree. With this sense
> of chrooting it would be more conventional to chroot the parent rsync daemon
> not each child since the parent could be compromised too and is running as
> root.
The parent isn't doing hardly anything except forking children so its
vulnerability is very low.
> I still think it is ok to chroot the child by default. I'm just saying if
> we allow children to spawn as client usernames, the child has normal user
> permissions. We no longer need to rely on chroot to restrict say,
> linking. The OS already restricts it accordingly for that user. Of course,
> we may still want to restrict any or all rules like linking in the server
> config, and we may still want to chroot the child, but now we are doing so
> for secondary protection and we move primary enforcement to the OS. The
> short of it is, I do not think we need to make any changes to the chroot
> functionality to implement --execute. It can be turned off. And I don't
> think we should let it side track this discussion.
>
> Regarding ssh alternative to --execute:
> Yes there are several reasons I would prefer --execute than ssh. First,
> without going into any details ssh will not be permissioned through my
> security infrastructure. second, even if ssh were an option I would still
> prefer to have both messaging and distributions happen over the same
> channel. This would avoid having two holes everywhere rather than one.
> third, I think it is much cleaner to make the execute part of the deployment
> engine rather than part of the wrapper. If it weren't, I would still need
> another mechanism to do the remote execution. Since rsync already has a
> connection, why not use it.
Well we don't want to add functionality to rsync if it can be easily done
by another tool because the more functionality there is the more there is
to maintain.
Again, consider using rsh if you're not worried about the network but are
worried about passwords on the servers. Here's a trick that may help
you: when using rsh, the remote rsync target may be any arbitrary shell
command that returns a list of files or directories. I use this in one of my
scripts:
rsync -a /srcdir/ remotehost:'`df -k . >&2;echo /destdir/`'
The output of df on the remote side sent to stderr and printed, and then it
copies to /destdir. This only works for pre-commands, but you could probably
make a clever --rsh or --rsync-path command to do what you want.
- Dave Dykstra
