RE: File permissions [make that directory permissions!]

[Tracy Brown]

Actually, my reply was not in reference to my own situation but rather
another mail. I do agree with Greg's sentiments about security and without a
doubt pserver is not secure.

There is some question as to how much security a UNIX account adds in an
internal environment. While an internal employee can spoof my pserver
configuration, users with a shell account can also spoof CVS unless
token-based authentication systems are implemented such as Kerberos, etc.
Perhaps there are configurations using SSH that can accommodate this.

I'm not questioning the security implications of my own configurations. In
my other configuration that is secure, I use Kerberos (GSS-API), tcp
compression, 3des encryption, database driven ACLs, and UNIX group
permissions. Yet, even in this configuration I do not need to hand out UNIX
accounts since users authenticate through my KDC (i.e. grab a TGT) and
access CVS using the gserver protocol. The CVS usage ACL is done within the
KDC - and the module/file level modification ACLs are done through a
combination of database queries and group permissions.

The purpose of my message was only to illustrate that in a relatively
trusted environment, pserver authentication does have some level of
accountability. While this can be spoofed, it may be unreasonable to go to
the depths of a highly secure environment depending on the sensitivity of
that data within the repository. I do not think that while the potential for
spooking is there in pserver, there is no accountability.

Tracy.


-----Original Message-----
From: Chris Cameron
To: CVS-II Discussion Mailing List; Tracy Brown
Sent: 5/22/01 4:37 PM
Subject: RE: File permissions [make that directory permissions!]

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