Noel L Yap wrote:
> [EMAIL PROTECTED] on 05/14/2000 09:50:23 PM
> >CVS with its own dedicated socket/port
> > run across SSH
> >
> > Transport secured, but the CVS socket/port
> > is open to the world on the remote machine,
> > and hence is insecure there, and on the
> > remote machine's network.
>
> If the data stream is encrypted, why do you call this insecure? How secure is
> secure?
If you use port forwarding, i.e. if you have a port on the client machine
that a client can connect to, that is forwarded across SSH to the server,
then you are only as secure as the security on that client machine.
Best if you have the clientside port enabled only for localhost, or even
user@localhost, but that is fairly easily spoofed.
If the forwarded port is open to all of the network segment that the
client machine is on, then you are only as secure as the least secure machine
on that network.
Anything involving port forwarding, even if the transport is secure,
has access to the forwarded port only as secure as the machine the
forwarded port lives on. Since you usually cannot rely on that,
then your security is only as good as the server connected to that forwarded
port - does it authenticate properly, expire tokens regularly, etc., etc.
Since many people set up SSH with trivial authentication - "Any process
on machine C can connect to the forwarded port and work on machine S,
once the SSH connection is established" - that doesn't count for much.
If CVS pserver is the only thing connected at the far end, then you're
only as good as CVS pserver's authentication. Which, according to what I've
read and what I've seen posted to this list, is not very good.
> >CVS using a non-socket/port transport like rsh or ssh
> > to connect to a server machine. "cvs server"
> >
> > As secure as the transport.
> >
> > E.g. requires account administration on the
> > machine on which cvs server will run.
>
> Why is admin access necessary in this situation?
The CVS server on the server machine manipulates data
in the server machine's filesystem. It requires some sort
of account identification to do this.
If you run the CVS server as some sort of anonymous user,
say "CVS", then, well, then you get what you deserve.
Most secure systems require that each user run with a separate
account id, for traceability, if nothing else. At the very least,
they prohibit writing data as an anonymous user.
If you're the one setting up the CVS server without sysadmin support,
and you allow it to use your account, same thing. Multiple users,
same account, no-no.
OK, so maybe you set up your own authentication system in CVS,
to "secure" usage of this single account. Of course, this is only as
secure as your (CVS's) authentication system - remember the posts
about CVS passwords? Any security administrator worth his salt
would/should prohibit this, or at least insist on auditing it.
Audit = account administration.
Or, best case, you give each user an account on the server, possibly
restricted. Now each user has a separate id. But, that's account
administration.
===
C'mon, Noel, you work for a bank! Surely you know this stuff!!!!
Or, perhaps better: I by no means have audited the security of CVS.
It is possible that CVS is secure. If so, I'd like to have someone explain
why it is to me, demonstrate it, etc. To date, from what I have read
in the CVS manuals, what I have read in the code, and from discussions
I have seen posted to this mailing list, my assumption is that CVS,
particularly CVS server, is quite insecure. My confidence in CVS's
security is not helped when I see posts that essentially say "CVS pserver
can use SSH, it therefore must be secure", since I do know enough about
security to know that that is not a valid line of reasoning. It may be possible
to properly secure CVS pserver across SSH; I'd feel a lot more confidence
if somebody listed the necessary steps, and if that list included the dozen
or so steps that I know a priori must be done.
I understand how to secure CVS on a networked filesystem like AFS.
First, make sure that CVS has no set-user-id components.
Then, make sure that the ACLs for the repository are set correctly.
Then, manage Kerberos authentication.
This is straightforward, and does not require auditting CVS source code.
It relies on whatever security auditing or trust you have in the
networked filesystem.
To develop the same level of trust in the various CVS server configurations,
you have to audit the CVS code and protocol. I.e. you have to develop the same
level of trust in CVS that you have in the filesystem. I.e. from the point of
view of security, *CVS* *SERVER* *IS* *A* *NETWORKED* *FILESYSTEM*.
