Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: CVS woes: .cvspass
From: Delian Krustev <krustev () krustev net>
Date: Fri, 6 Aug 2004 19:27:57 +0300

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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault