Date: Fri, 6 Aug 2004 19:27:57 +0300
From: Delian Krustev <krustev@...stev.net>
To: bugtraq@...urityfocus.com
Cc: woods@...rd.com
Subject: Re: CVS woes: .cvspass


Your mails are getting longer and longer. Please try saying more
in less words next time. Thank You.

On Thursday 05 August 2004 23:11, Greg A. Woods wrote:
> It's not possible to "secure" CVSpserver using IPsec.  Period.
>
> I.e. it's just not logically possible, using CVSpserver, do do what you
> said could be done.  To do so violates the fundamental security model of
> CVS and the Unix(like) systems it runs upon.

There's nothing like "fundamental security model". Not in unix/linux, nor
in CVS. I suppose You're talking about UID/GID based security.

I'll repeat myself. Security could be guaranteed on different layers.
In the software case - operating system, application, components, etc ..

Please tell me what, from the things I've said, is not "logically possible"
to be done and I'll provide an example.

> IPsec can only secure the inter-host network links and thus make it
> possible to securely use CVS via remote job protocols such as RSH (which
> use host-level security techniques and assume their virtual circuits are
> already secure) instead of requriring SSH.  IPsec does not operate at
> the user level and even if it did ..

<bold>
>.. you'd still require unique system
> identities for every individual human user.
</bold>

The local access to the repository requires each commiter to have direct
r/w access to each of the directories inside the repository. This gives
him the power to compromise it in anyway he likes. The commits performed
by locally executed cvs command are performed by creating/renaming/unlinking
files.

> Note that even pushing the IPsec implementation away from the host
> kernel and onto a gateway router implies blindly accepting many more
> assumptions about the security of the local area network.

The keyword here is opportunistic encryption. The nodes of trust
will be the server, the client and the client's DNS provider. The third
one could be eliminated. No lan security is involved in that scenario.

> The whole point of security, i.e. authentication, authorisation, and
> accountability, is to relate all internal system activity back to real,
> verified, authorised, individual human users.
>
> I use the common phrase "human user" to differentiate the real people
> who use a system from the identities they assume, or rather are given,
> inside of a computing system environment.
>
> It is fundamental that each system account be used by one and only one
> unique human user.  Without this condition accountability is impossible
> (at least for the users of that shared user-ID) unless it's provided by
> some external means (e.g. a security guard at the door of the
> Tempest-level room where the computer is located who is instructed to
> securely record every access to the computer, and who is capable of
> securely performing this duty).

Not right. The services are virtulized nowadays. Each one could provide
it's own privilege/accounting methods(guaranteed on application layer).

> It is also fundamental that every system activity performed by a human
> user be performed using a unique-per-human _system_ level identity.  If
> you do not meet this condition then you are violating the fundamental
> security model of the system and all bets are off, all warrantees null
> and void, etc.

No "fundamental security model". Nothing to break.

[snip]

There's nothing concreete in your words. All you're talking about
is fundamental principles. That makes me think You've never managed
a single cvs repository.

Powered by blists - more mailing lists