> I hate to point it out, but you seem to be a little confused. First, if you
> "export" the repo with AFS/NFS/DFS/etc, that repo will not be accessible with
> other tools (such as rm, mv, ln, etc).
??? I assume that you meant "the repo will be accessible with other tools".
I do this regularly - manipulating files in the repository across AFS,
for those situations when
> In other words, yes, you only have to
> trust the AFS system, but if you can't trust the client that is running AFS,
> then you are screwed anyways. (I can trojan AFS code to do malicious things).
No. A proper secure network filesystem does not trust the filesystem client code.
The client may be corrupted, but it can still only access things for which there
is a valid token on the client side. Yes, you can trojan the client, and thereby
get access to files of the user(s) working on the client, but you cannot get
access to other users files.
What you say is true of NFS, however. NFS does enforce security via
client-side code.
> Very true, however, I fail to see how AFS is going to change much of this.
> Yes, you can compartimentalize where and who writes what, but you still need
> to administer "account" information, information that specifies which users
> in the AFS cloud can write with which credentials where. How is this any harder
> than local (yp, etc, etc) user administration? I think the only argument you
> can make here is that there is a potential for being more secure, at the
> expense of having (I really wanna use the word "stupid" here) novice people
> poking through a repository with other "tools" (vi, rm, mv, ln, etc)...
Yep. But now the account and privilege administration falls into
a standard and well-understood framework. The full system sysadmins
get to control who can run programs on their machine, without CVS
providing a possible backdoor. The users, not necessarily sysadmins,
who manage CVS can control the filesystem that holds their repository.
It's straightforward to use ACLs to give read-only access to parts of
the repository, the ability to only edit existing files but not to add new files,
etc.
You can, if you want to work hard enough, start using the setuid and
capability system to allow novice users to use CVS add but not to
be able to use non-CVS tools on the raw filesystem. That's a whole other
set of issues. I've been there, but I really prefer to work with a skilled
team of non-novices who know when to access the repository directly
and when not to.
> Yes. At worst case, your web user has system access
Yep. Some secure sites run "web servers" under AFS, by making
all of their URLs point to files in AFS. This way the browser
accesses the file as the user. This approach also means that
you don't have to set up a ^%$$##@#$#$$^ password system
for restricted web pages - once again, the AFS ACLs handle it.
> your lpd daemon package has system access (likely even root holes).
Yep^2. In Gould Secure UNIX, the line printer was a perennial problem.
Overall, the solution seems to be true spooling - instead of the optimization
that allows lpd to read from a file in place, to always copy a file to the
spool directory, and then to take care that lpd doesn't screw up.
(One problem was that lpd once managed to skew control files
and data files, and printed the next print job for the previous user.)
> I think a safer
> approach is to run CVS in client-server mode, using only ssh (as far as
> is possible) to access the repository. Then, for each user that needs to
> commit things, create a login/UID for that user, with a special shell.
Yes, this is the thing to do
(a) if you must use CVS server
(b) if you can get sysadmin suppprt.
But, this "increases the overhead" of setting up CVS.
On a filesystem, ordinary users can set up their own repository
without having to ask the sysadmins.
I'm assuming that you are not using port forwarding...
> For "greater" security, a chroot() type of mechanism could be
> implemented (it would take some more work)...
I'm a great advocate of chroot.
I worked at Gould, next to the people who did Secure UNIX.
> There is close to some truth here. In both methods, you have to trust almost
> the same amount of code. The CVS code is there with both methods, one is client
> side, the other has the extra code server side. On the one hand you have to
> trust the AFS/DFS/NFS/etc code, on the other SSH or whatever transport you wish
> to use.
.... ahhh, I think I noticed the chief difference between us.
Your main concern seems to be the security of the repository.
I agree that this is important, and I agree with you that raw
filesystem access to the repository can allow novice users
to break things badly.
My main concern, however, is the security of the overall system,
and the security of other user's files that are managed by CVS
that are not supposed to be accessible by the first user.
Other repositories, if you will, or, more likely, other source
trees in the same repository. (Because CVS server is
somewhat heavyweight, people have a bad habit of setting
up a single repository to manage multiple projects that really
need different protection levels.)
