[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: File permissions [make that directory permissions!]

From: Greg A. Woods
Subject: RE: File permissions [make that directory permissions!]
Date: Tue, 22 May 2001 18:43:37 -0400 (EDT)

[ On Tuesday, May 22, 2001 at 14:19:42 (-0700), Tracy Brown wrote: ]
> Subject: RE: File permissions [make that directory permissions!]
> I'm a little confused. For my user base, none have UNIX shell accounts. 
> In the pserver password file:
>       user:password:user_to_run_as
>       i.e.
>       bob:lsfdkuhsdf:pubcvs
> The $USER var will return the user (bob) and not the optional user_to_run_as
> (pubcvs) as noted in the above example. Thus, I can hold my users
> accountable to their modifications made in the repository.

Where do you get that idea?  There's only one user accountable for the
repository and that's the user the pserver thing runs as.  Any apparent
accountability offered by pserver is only an illusion that cannot be

Accountability in Unix *requires* Unix user-ids for each entity that's
to be held accountable.  You cannot eat your cake and have it too.

Note that because CVS is not a security tool and thus does not have any
real security within it, it cannot do secure authentication and secure
authorisation and it cannot prevent one fake user from making it look
like some other fake user did something in the repository.  CVS pserver
has no accountability whatsoever.  You are dreaming if you think
otherwise.  It also has no privacy whatsoever (unless you tunnel it
through SSH, but that's rather pointless since you've got to create Unix
accounts for SSH anyway).  Without privacy the passwords, the code,
etc., all passes over the network in the clear and without any
protection from man-in-the-middle attacks (such as connection hijacking,
connection spoofing, etc.).  Trivial off-the-shelf tools will allow
anyone with access to your network to do any manner of things to a
pserver connection.  With a tiny amount of additional work this might
even include doing things like stuffing trojan code into your repository
during a commit by someone else!

> As an administrator I really don't want to manage 100+ UNIX accounts just
> because I should trust them... that's a hassle. And we don't need to - 
> we can obtain accountability without this silly hassle.

You would rather administer fake accounts in some insecure application?!?!?!?

Real unix accounts are most definitely *NOT* any kind of "hassle"!
You're fooling yourself and focusing on the wrong issues.  When you go
to get a driver's license it's not just a photocopy of some master --
it's a unique document personalised to the person it is granted to.

Note that you don't have to *support* full shell access to the server,
but you do have to be aware that the possibility is there and that it
cannot be prevented, pserver or not.  (SSH+chroot might be able to
restrict what parts and services on the server are visible and usable by
the user, but otherwise don't change the equation w.r.t. the repository
itself; and I personally would never use them in place of having a
separate server.)

If you're offering access to important files on your system then you
really do want to create real individual Unix accounts for each and
every entity you authorise such access for!  With only fake pserver
accounts you're providing all of the trappings (and hinding behind them)
but none of the substance of real security controls.

You are in fact implicitly trusting pserver users with what ammounts to
shell access as the pserver user -- you just don't have any basis for
that trust because you really cannot hold them accountable and you have
not really authenticated them.  Without using some external auditing
process where the programmers are each individually required to
re-verify the origin and intgrity of each of their changes the code in
that repository could have been changed by anyone with IP access to the

If you don't want to add Unix user accounts for each real user then
please don't fool yourself into thinking your repository (or even the
system it resides on) is secure -- treat its status for what it really
is:  an anonymous repository.  You'll probably even be more secure
overall if you don't have any passords on the pserver accounts -- that
way everyone will be forced to be more aware of the situation and will
look out for each other and for intruders.

Note of course that if your machine is physically secure and if you have
an external security policy covering all your users with remedies that
will prevent them from violating that policy without paying the price
then much of what I say above may be irrelevant for your specific
situation.  However if the "rewards" are high enough for an attacker
then the "threats" imposed by an external security policy may not be
enough of a deterrent to stop the attacker, and so without real
accountability and true technical controls in your systems you leave all
the other users open to redirection of suspicion.  In other words it's
only sane to apply all of the available technical controls which will
help enforce your security policy and to thus protect your users from
each other, regardless of whether or not they can do permanent damage to
your repository with or without such controls.  If I were one of your
users I would demand a real Unix account so that none of the fake users
could do anything in my name!

                                                        Greg A. Woods

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]