RE: File permissions [make that directory permissions!]

[Chris Cameron]

Without contradicting any of Gregs comments on security, which have been
aired in this forum too many times to count, I feel that Greg's last
paragraph is the most relevant.  What is the background to the original
question?  Is this an internal or external project?  What are you trying to
protect against?  Malicious users or uses who may do potentially damaging
operations without being aware of it?

***************************************************************
Chris Cameron                       Open Telecommunications Ltd
Product Manager                           IN Product Management
address@hidden                           P.O.Box 10-388
      +64 4 495 8403 (DDI)                          The Terrace
fax:  +64 4 495 8419                                 Wellington
cell: +64 21 650 680                                New Zealand
Life, don't talk to me about life ....(Marvin - HHGTTG)


-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of
Greg A. Woods
Sent: Wednesday, 23 May 2001 10:44 a.m.
To: Tracy Brown
Cc: CVS-II Discussion Mailing List
Subject: RE: File permissions [make that directory permissions!]


[ 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
verified.

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
machine.

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>

_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs