> > ** CVS across AFS or DFS
>
> How does the later improve in any way on the former?!? If the client is
> not secure, AFS and/or DFS is not going to help you in much of any manner.
Short answer: in the latter (CVS on top of AFS) CVS does not need
to be trusted. Only the filesystem needs to be trusted. In the former
(any CVS server system) the CVS server needs to be trusted.
Long answer:
If the CVS client or server code is insecure,
if the CVS server is running as some anonymous OS user
with its own password code managing multiple CVS users,
then any bugs would allow any of the CVS users to munge
anything belonging to any other CVS user.
"Munge" includes reading data and corrupting data.
Or, anything accessible to the anonymous OS user account.
In this case, "munge" means data access, and possibly
program execution.
God help you if there are setuid programs running around,
or if the anonymous OS user account under which the CVS
server is not a relatively unprivileged "cvs", but has more
privilege, even, possibly, root.
I.e. basically all of the CVS user-ids and the OS-user-id under
which CVS runs must be considered to have the same privileges
for worst case analysis -- at least until CVS passes a security audit.
With CVS running on top of a network filesystem,
your security is that of the filesystem.
CVS runs with the privilege of the user running the CVS
command. (Let's forget about the possibility of CVS running
setuid.)
If the CVS program run by the user is insecure, well,
then the user can access.... exactly the files that he could access
without running CVS.
If the client machine is insecure, then the user can access...
only the files that it can authenticate itself to the fileserver for.
I.e. worst case, an intruder can take over the client machine,
munge around in the virtual memory of other processes,
find valid tokens, and use those to access the fileserver
as the user whose process he intervened with.
Note that the intruder cannot just record the network traffic, since
the tokens are not passed. Note that the intruder has to take
over the process whose tokens he is intercepting, since they
are probably nonces - challenge/response is time and sequence
number sensitive. Note also that such tokens live in memory
in any reasonable system, not on disk - you *have* to gain
kernel privilege.
As soon as those tokens expire, the intruder cannot authenticate
to get any new ones. Nor can the intruder authenticate himself
as any other user except for users that are working on the system
he has taken over.
====
Note: this is not specific to a filesystem. It's just good authentication.
Kerberized SSH or CVS runs this way... as long as it is not doing
port forwarding on the remote (client) machine. It's just a question
of what pieces of code you have to trust. With CVS server,
the CVS server code is within the trust boundary - for all intents
and purposes, it is part of the security system. With CVS on top
of a filesystem, the CVS server code does not need to be trusted
- the trust boundary includes the filesystem, but not CVS.
The less code that you have to trust, the easier it is to give yourself
confidence that the code is secure.
