dropbear, cvs, and checkpassword

[Andy Goth]

Matt Johnston wrote:
> On Mon, Sep 05, 2005 at 10:33:43AM -0500, Andy Goth wrote:
> > 1. Create svr-authcheckpassword.c.
> > 2. Add a #define for it.
> > 3. Add to svr-auth.c some code to call my new function.
> 
> Yeah, I think that sounds fairly sane. You can probably base
> it pretty closely on svr-authpasswd.c, just get rid of the
> crypt() stuff etc.

I don't expect that to be the hard part.  I expect the unknowns to be
the hard part.  See below for a few I unearthed while reading sources.

> > 4. Defeat checkusername().
> > For my version I'll just make a #define wrapping the call to
> > checkusername(), or maybe I'll have it comment out the guts of same.
> > I don't know yet.
> 
> checkusername() is a little bit more awkward - other parts
> of the code such as svr-chansession depend on the call to
> getpwnam() for finding out which shell to execute, homedirs,
> etc.

Ah, so checkusername() has the side effect of modifying global variable
ses, which is read everywhere.  Hmm.  Hmmm.  I didn't catch that the
first time I looked.

> It might be best to make it call getpwnam() on the actual unix
> username, and use that.

This gives me something valid to put in $USER/$LOGNAME, gets the right
UID for the benefit of execchild(), and makes pty_setowner() happy[*].
But it also gets a home directory incompatible with the behavior I want
for checkpubkey: I'd like for each CVS user to have his own keys, rather
than sharing mine.

[*] Does anything in sshpty.c work when dropbear isn't running as root?
 For non-interactive character-oriented usage such as that required by
CVS, is anything in sshpty.c necessary?  If the pty stuff fails, will
dropbear abort or continue anyway?  Maybe I can force sessioncommand()
to use noptycommand() or abort on chansess->term != NULL.  The CVS
client shouldn't be providing it ssh child with a terminal, so the ssh
client shouldn't be asking the ssh server for one either.  Right?

> > Of course everyone will log in as me.  For this reason I'll have to
> > do something to ensure that dropbear will only run "cvs server".
> 
> Have a look in svr-chansession.c, for your purposes you can
> probably just hardcode a program to execute.

I'll make it abort when the command is anything other than "cvs server".
 That confuses ordinary ssh clients the least, and it gives attackers
the least amount of clue about how to crack in.

> > I'll also need to look at cvs to see if it can be convinced to read
> > or overwrite files not in the CVS repository.
>
> I'm not sure how easy it is to secure CVS - I guess various other
> projects seem to have set up similar things before (though perhaps
> not all as a single user).

Crud crud.  In the :pserver: CVS method, the client sends the CVS
username to the CVS server in the AUTH REQUEST.  But with :ext: the CVS
username is never sent, because authentication is thought to already
have been performed by the rsh/ssh server.  Moreover, :ext: CVS doesn't
do any permissions checking (which modules can the user access, etc.)
since it leaves that up to filesystem permissions.  :pserver: has all
the features I want, except for friggin' SSL.  :ext: has all the
features I want, except for friggin' permissions.  CVS = too clever.

Looks like I'll have to modify CVS's server.c to set CVS_Username to
$USER thus convincing itself it's using :pserver: rather than :ext:.
(It seems like a questionable design to use that variable as the
discriminant, but so long as it's the only one, I'll be fine.)  This
also means I'll need to make dropbear set a phony (from UNIX's
perspective) $USER.  Will this cause problems?  If so, I could make a
new variable, $CVSUSER.

It would be nice if I could just connect the CVS client and server with
sslclient/sslserver (http://www.superscript.com/ucspi-ssl/intro.html).
Then I could forget all about ssh.  Maybe I should propose a new CVS
repository method, :stdio:, which would be :pserver: without the TCP.  Hmm.

-- 
Andy Goth
   <amgoth at link.com>
   <unununium at openverse.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20050907/b37b5c8d/signature.pgp