>>>>> "DRP" == Derek R Price <[EMAIL PROTECTED]> writes:
I'm somewhat sleepy and my language will act accordingly :)
DRP> Is there some reason I shouldn't view this as a security hole?
DRP> Without debating the lack of real security in pserver mode
DRP> already, an open source client such as CVS's is so easily
DRP> hackable that a sensitive system becomes even more insecure.
DRP> User X can easily log in and make changes which will be logged as
DRP> having been made by user Y.
Hm. I do not know much about Noel's scheme, but as far as I am on Cc:
list I will speak of http://alexm.here.ru/cvs-nserver/.
Seems to me that the acceptable possibility to use several cvs users
with only one corresponding server machine user is:
- client says "hi, I am cvs user 'pete' with password 'god'";
- server checks against its cvs users database and says "ok, welcome,
dear pete", and then, not telling pete anything, setuids to some
system user, 'cvsuser';
- when another client comes and says "hi, I'm cvs user 'mary', with
password 'his-mother', will you let me in?
- server checks against cvs users database and says "ok, welcome,
mary", and then, not telling her anything, setuids to the same system
user, 'cvsuser';
Now mary and pete are not protected against each other, beyond their
good will towards each other (one way to protect them will be
implementing ACLs directly in CVS, but that's another story, as most
sites do not need to protect agaist each other, and if they need they
could always setup another repository with another back-end system
user).
This is exactly how it is implemented in cvs-nserver (now in beta).
Note that the initial words from pete with his username and password
cleartext could be in not so clear text, for example, after
implementing pserver-over-SSL (that's top priority in nserver). Also,
the following conversation with sending sources to each other would
not go unprotected in Internet jungles (note that channel encryption
is completely orthogonal to server-machine security and mapping of
cvs- to system-users.
DRP> I can see using a trusted authentication system to set the
DRP> variable, but use the CVS client???
Hm. Do you REALLY speak of scheme where:
- client says 'ssh [EMAIL PROTECTED]', and says real password
for 'cvsuser' (that's system account on server machine);
- server says ok, welcome;
- client says, 'oh, wait, could you please forget about what I've said
first time, that's just you wouldn't let me in otherwise, but let me
introduce myself for real now: I am 'dave'. Just 'dave', without any
words to pass you.
- 'oh,' says server, 'I too was slightly surprised when someone said
he's 'CVS User', such funny name. Pleased to meet you, Dave, come in.
??????????? You surely _have_ to demand second password, and to
authenticate against separate list of cvs users and I think that I
look stupidly trying to explain evident.
So the first 'ssh' was just to ensure that the second password goes
very well encrypted.
DRP> I think even hacking SSH to do this is fairly insecure, as there
DRP> is no way that I know of to verify that the SSH client is "pure"
DRP> and it can only authenticate that key and user are valid on a
DRP> server machine. Therefore, if an SSH client authenticates on the
DRP> server as the generic user and sends a simple "my name is X" from
DRP> a particular machine, there is no way to know that the user is
DRP> really X on that machine. And that doesn't even take into
DRP> consideration the nightmare of a user setting up a clean machine
DRP> and adding any user ids to it that they'd care to and connecting
DRP> from there. I imagine that if SSH servers could authenticate
DRP> against each other and verify their and their users identities
DRP> something might be riggable. Is that possible as things stand?
If Renegade-CVS demands second password, then it's completely ok and
nserver mostly does not go beyond it with regard to functionality (if
you do not want: a) remote administration of repositories; b) other
methods of channel encryption, i.e. SSL; c) much cleaner codebase; d)
PAM support ;) ).
Nserver just cleanly separates "Communication Channels" (unprotected
plain-text, SSL-tunneled or even ssh-tunneled), "Authentication"
(checking that client is really who he pretends to be, via /etc/passwd
or via CVSROOT/cvspasswd or via PAM) and "Authorization on server
machine" (i. e. setuid(), including mapping of CVS users to system
users).
For example, you could install something like this on server machine
ssltunnel cvs-pserver /bin/checkpassword-pam cvs pserver
(SSL-tunneled pserver authenticating over system PAM database and
using :pserver: protocol)
or
ssh --tunnel cvs-nserver /usr/bin/cvschkpw cvs nserver
(SSH-tunneled nserver authenticating over CVS users database working
under single system account and using :nserver: protocol (XML-based
vapourware that should replace :pserver:)
or even
cvs-kserver cvs pserver
(Kerberos-authenticated and encrypted :pserver: protocol).
Variations are really endless.
This introduces additional benefit of very simple and short
cvs-pserver.c, cvschkpw.c and other security-critical programs
(currently they are near 200 lines each) (and cvs binary itself does
not contain any setuid() call). Compare that to server.c (>6000
lines) and client.c (slightly less than 6000 lines).
Please note that it is very easy to write portable CVS-client that
securely speaks to cvs-(n)server via SSL while it seems to me much
much more trouble to try running ssh.exe under windows and tunneling
anything over it.
Thank you if you have read this far :) The nserver plug is almost
over.
Welcome to http://alexm.here.ru/cvs-nserver/.
--alexm
