Wow, fast reader you. Thanks for your reply Dave,
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.
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.
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.
--Henry
-----Original Message-----
From: Dave Dykstra [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 12, 2001 1:22 PM
To: Wrieth, Henry
Cc: '[EMAIL PROTECTED]'
Subject: Re: --execute option
I'm not going to comment on your entire message, just pieces of it:
On Mon, Feb 12, 2001 at 12:53:39PM -0500, Wrieth, Henry wrote:
...
> -Authentication:
> If we are going to spawn the child as the client user, we need to be
assured
> the user is who he or she claims to be. Currently, rsyncd uses a
password
> file with arbitrary users (users not necessarily on the host) and a clear
> text password, or secrets file. It is secured by 'root read only'
> permissions. Modules may permission allowed users from that list. We all
> recognize that the secrets file is a good, but antique idea and does not
> pass audits any longer. My only recommendation is that we upgrade the
login
> functionality to allow native OS usernames and passwords. Then perhaps,
we
> extend this later to include LDAP, radius, kerberos, PKI, etc.
The reason why the password is in the clear in the secrets file is not an
antique idea: it avoids having to send the passwords in the clear over the
network, which you cannot avoid with native OS usernames and passords
unless you use encryption like SSH does. Having the password in the clear
on the server side enables using it as a key for a random number challenge-
response which rsync does behind the scenes.
> --execute
> Once we have child daemons securely spawning as normal users we can have
no
> worries about adding an --execute option. I say this because we are not
> granting any new privileges to the user which they do not already have by
> logging onto the box directly. Jil can not do things as Jak, Like send
> nasty mail to his boss, and can not do things as root like, rm /.
Keep in mind that it's not just the user id authentication we're concerned
about, it's also the chroot environment. The chroot is a safeguard against
holes in the rsync server implementation and not one we're usually willing
to give up.
> -Summary
> I think --execute could become a safe and extremely powerful addition to
> rsync by making two relatively simple changes to the existing daemon.
>
> 1.) When 'uid=' is not specified in a module spawn the child as
> the client username
> 2.) Update the login function to allow native OS username and
> password. 'login=native'
>
> Now we can create an --execute feature to allow execution of arbitrary
> scripts either before or after file deployment and either 'on success' or
> 'on failure'.
> --execute="/path/doit -q arg" after_deploy on_success
>
> Perhaps it be required that if the --execute option is used then either
the
> uid= or login= be enforced. That is I don't think --execute should be
> allowed in anonymous mode.
Serious suggestion: from what I understand about your application now, it
seems to me that using '-e ssh' would be the best way for you to go instead
of an rsync daemon. Is there a reason why that's not an option for you?
- Dave Dykstra
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. CREDIT SUISSE GROUP and each of its subsidiaries each reserve
the right to monitor all e-mail communications through its networks. Any
views expressed in this message are those of the individual sender, except
where the message states otherwise and the sender is authorised to state
them to be the views of any such entity.
Unless otherwise stated, any pricing information given in this message is
indicative only, is subject to change and does not constitute an offer to
deal at any price quoted.
Any reference to the terms of executed transactions should be treated as
preliminary only and subject to our formal written confirmation.
