Re: ANN: cvssh - secure ext-to-pserver bridge

[Greg A. Woods]

[ On Thursday, February 21, 2002 at 18:59:36 (GMT), David A. Desrosiers wrote: ]
> Subject: Re: ANN: cvssh - secure ext-to-pserver bridge
>
>       Except in the cases where using pserver is actually _MORE_ secure
> than giving users a valid unix account on your server.

There's only _EXACTLY_ one case where cvspserver is in any way more
secure than giving out real accounts, and that's when pserver is used to
give read-only anonymous access to a _copy_ of a repository.  Period.
No ifs ands or buts.  Period!

Use of cvspserver for commit access is _EXACTLY_ equivalent to giving
anonymous commit access to your repository, and that goes double if
access to that service is possible from anywhere outside of your trusted
private network (because of course anonymity of access is much more
certain from anywhere outside your immediately secured domain).  It does
not matter one hoot if cvspserver is tunneled through SSL, SSH, or IPsec
or whatever -- any access from "outside" is, by definition, from an
uncontrolled, unauthenticated, source.

> I could very well
> trust my developers, and give them shell accounts, but I can _NOT_ trust
> their machines, their network, their personal accountability when they 
> are 9,000 miles from my location.

Then you've already lost the game.  Thanks for playing.  To bad.  So
sorry.  Better luck next time.  Bzzzzzzt!!!!  Next player!!!!!

YOU __MUST__ TRUST THE CLIENT HOST, IMPLICITLY, 100%, EVEN WITH SSH!!!!!

MUST MUST MUST MUST MUST MUST MUST MUST MUST MUST MUST MUST MUST MUST.

The client host is, for _ALL_ intents and purposes, the equivalent of
the user using it.  Even if you do not trust the client host to have
identified and authenticated the user, you MUST still trust the client
host to proxy the user's actions (and your host's replies to the user)
with the exactly the same (or better) security as you require of the
user himself or herself.  The only case where that is not true is when
you and you alone control the remote client host 100% and you have
implemented physical security measures to prevent the remote user from
disrupting it in any way (i.e. measures at least equal to any threat you
feel from the remote user _and_ any others with similar levels of
physical access to that host).

Now what's interesting here is what is meant by the word "trust".
Security is not some absolute binary condition.  It's a response to
threats that could reduce the value of whatever you're protecting.  In
this instance you MUST TRUST the client host in so far as you grant it
access to your system(s) and your data.  In other words you MUST TRUST
the client host to maintain the same level of security (integrity,
privacy, etc., etc., etc.) as you trust the user who you have granted
specific authorised levels of access.  If you do not control the remote
client host 100% then your security policy must make it blatantly clear
to the remote users that they themselves are required to maintain the
same level of security on their client hosts as you need in order to
grant them access to the servers you control.  You must also implement
controls and auditing to ensure those remote users maintain the
necessary levels of security as you've defined them and you must revoke
their access when you cannot confirm their conformance.  You cannot do
any of that unless you have unique system user-IDs for every user.

In other words if you've given an account to an user to access a CVS
repostitory hosted on your network then you _MUST_ do whatever is
necessary to isolate that user's access from the data and services on
your network and in your systems that you do not trust them to access.
I.e. you give them limited trust.

This also implies that you _MUST_ equally trust each user of the same
repository at the same level.  If an of those users is also to be
trusted with more access to your other systems then you MUST give them a
different unique user-ID and separately authenticate them for the higher
level of access.

In other words you must comparmentalize access to your shared CVS
repository so that remote users can gain secure access to it while not
gaining access to anything you don't want them to access.  This probably
means building a separate dedicated machine on which the shared repo is
hosted and assigning unique individual accounts to every user (remote or
otherwise) who is to be granted any kind of access to that repository.
This also means writing a security policy for the remote users that
clearly states the security requirements you have for them and their
client hosts and to implementing whatever controls (technical or
otherwise) and auditing procedures are necessary to maintain the level
of security you require for that CVS repository.

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>