Re: CVS access control

[Tobias Brox]

address@hidden - Thu at 09:09:13AM -0400]
> This is true.  That's why security devices (at least safes) state how
> secure they are (eg it'll take a competent burglar with a blow torch 30
> minutes to break in).  Unfortunately, no such descriptions exist in the
> computer world.

It's always important to document security concerns properly, also in the
computer world.  How many hundreds of years a pentium computer would need
for breaking the encryption seldom much relevant - it's far more important
to state /if/ a program actually was written with security in mind or not,
what kind of possible holes, backdoors and possibilities for cracking in
there can be, etc.

I'm quite sick of internet banking services where the bank (of course)
states "this solution is 100% secure!".  Most of the services I've seen have
no security at all against possible trojan horses at the client computers -
anyone with root permissions and enough knowledge and skills might hijack
the session.

To get back to where this discussion started - we were discussing
possibilities for adding ACL into cvs.  If CVS had ACLs, and they were
securly implemented, it wouldn't help at all, you said, because the user
anyway could go directly to the repository and do whatever he liked.  That's
not so true - the _documentation_ must clearly tell about this possibility,
and what countermeasures the system administrator might do to cover it up.

Countermeasures does exist, we've seen that SSH can be configured to only
let people execute cvs, and we've seen that it is possible to run CVS
set[gu]id (though not recommended, as CVS never was implemented to be
secure)

> >Passwords sent in plain text through the network is a bit safer than no
> >passwords at all - the number of people that are likely to break in is far
> >lower.
> 
> This is true since it takes at least some effort to sniff the packets.
> Just about anyone in the world can get through a knotted rope.

So, the knotted rope can be compared with a message telling: "Go away, don't
break in here".  Still, the message does offer better safety than no message
at all.  It would usually suffice for a toilet door, to tell that the toilet
is occupied.  Even juridically, a person coming into the system and causing
harm can probably be sued for it if and only if it should have been clear
for him that what (s)he did was wrong.

Ok, this is nitpicking and has nothing to do with cvs.  Let's drop it here.

> >Still, "real", 100% security is always non-sense - you would probably be
> >willing to help me find some way around the ACLs if I "visited" you and
> >started pulling out your nails.  (...)

> This is true but it would require a bug in something that's supposed to be
> secure.

Sorry for beeing unclear again - if _you_ can log into some server as root,
you _can_ help me to get around any ACL there might be at that server,
regardless of what bugs there might be.  And then again, there might be a
myriad of ways to "pursuade" you to help me.  As long as any human knows a
password, there are ways to get into the system.

> >For those that don't care much about "real" security, "security by
> >obscurity" is certainly a lot better than no security at all.
> 
> Any security professional would never rely on "security through obscurity".

"Security through obscurity" should always be avoided, I've never ment
anything else.  "Real" security (in the computer context) is to close down
all known security holes, avoid (as far as possible) exposure for unknown
security holes, restrict the damage that can be done through unknown
security holes, and trap possible intruders through system surveillance
(i.e. tripwire).  Have I forgotten anything?

Still - security through obscurity /is/ better than no security at all!

-- 
Unemployed hacker
Will program for food!
http://ccs.custompublish.com/