On Monday, May 15, Andy Glew wrote:
> > > ** 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.
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). 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).
Also, about trusting the CVS server. In 99% of the cases, you have little
to no option but to do that anyhow. Using various cryptographic techniques
(such as ssh uses, etc), you can make reasonably sure that nobody is spoofing
your server, but once connected to your server, you little recourse, but to
trust what it does. The same holds for the AFS case, the AFS server has to be
trusted by any AFS clients as well...
> 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.
Ahh, the anonymous CVS server scenario. If you don't trust CVS to do its
thing correctly (and many of us don't), then I'd suggest using a wrapper,
along the lines of anoncvssh, that also does appropriate chroot() calls to
encapsulate things appropriately. Alternatively, you could recognize that
CVS does anonymous (meaning without using machine IDs) rather poorly, esp.
if those users need commit access. Granted, not really a solution.
> "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.
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)...
> 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.
Yes. At worst case, your web user has system access, your lpd daemon
package has system access (likely even root holes). 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. This
shell (a version/variant) of anoncvssh would do sanity checking of arguments
and decent logging of where and how people were connected. Along with some
simple ssh config tweaks (such as RSA key needed, etc) this should be reasonably
secure. For "greater" security, a chroot() type of mechanism could be
implemented (it would take some more work)...
> 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.
Very true. However, along with the performance problems that this original
note sparked (and that I have seen first hand), this also opens up the repo
for manipulation by any "authorized" users with any "tool" they choose. I've
recovered a lot more corrupted repos due to this, than through a malicious
hacking attempt that actually succeeded.
> 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.
Exactly, so he can rm the files just as easily. With CVS client-server,
he/she would need to break the server in order to do that much damage.
Also, with client-server, logging would have led me to his house with a big
stick, in order to 'cap his knees... :-) With AFS (or another filesystem),
the attacker could do such things, and nothing would be the wiser who or
what happened to do it (unless you log all filesystem activities at the
server, something I'm guessing would be rather prohibitive)...
> 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.
Yes, something that is not that hard to do. All you are telling me here
is that you have to trust the client either way, just as you have to trust
the server in both scenarios.
> 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.
If I trojan AFS, I can take over each user as they log in. With a nice
random number generator, and a probability function of some 0.01% of the
time being evaluated to TRUE, I can silently and slowly corrupt your AFS
spaces, whatever they may be. Repo, CVS, whatever. By the time you realize
it, things may not even exist on backup anymore...
> ====
>
> 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.
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. The two reasons I've always decided upon client-server are performance
(over remote filesystems), and reliability. The reliability is the main one
here, I can restrict CVS users to sticking with CVS, and not muck with the repo
with other files. I have 1 point of control over where people/users go through
in order to access the repo. I have 1 point of good logging. Also, since I
control the server to a much greater degree than the clients, I like to know that
I can tie down my system, and have only a few possible known exploits, without
having to worry about the security consciousness and practices of other developers.
In other words, another maxim (of sorts) of security is that you give users a
tool just large enough for their jobs, not larger. In some sense, full file
access (through AFS/DFS/NFS/etc) is a much larger tool than most of these people
need, and present a greater danger, IMHO, than the possibilities through the CVS
protocol.
--Toby.
