On Wed, Aug 09, 2000 at 01:37:01AM -0600, Tobias Weingartner wrote:
> > > Any sufficiently powerful language is effectivley Turing Complete --
> > > i.e. will allow the cracker to do dangerous things.
> >
> > This sounds clever, but everything it says is wrong: there are turning
> > complete languages that are not dangerous, and there are languages which
> > are sufficiently powerful (for some purpose) but not turning complete.
> >
> > You're just trying to sound clever, but it's not working.
>
> It's Turing, not turning.
Weird. Sometimes my fingers have a life of their own. I made that same
typing mistake twice there, and twice more in responding to this. I must
reflexibly type 'turning' or something.
My point is that I can give Greg a turing machine with a finite tape (no
real turing machine has an infinite one) and he can move the single
head up and down all he likes and it'll never give him access to
any network interface or disk space. His attack will be limited to
implementing trivial algorithms from 1st year computer science that
chew up a lot of CPU time and possibly make my machine a bit slow. But if
I run his little turing machine niced, he won't even slow me down.
Not all turing complete languages give an attacker anything interesting
to do. The proof is that a turing machine itself isn't something that an
attacker would find interesting.
Furthermore, there are useful languages that are not turing complete.
They provide just enough functionality that you can perform the task
you are trying to perform--but they don't give you any capability of
writing general purpose programs.
Whether a language is equivalent to a turing machine is an irrelevant
attempt to sound clever.
> For all intense and purposes, we are talking about some data
> (whatever it may be, language, etc) being read and or manipulated
> by a C program. Should there be a fault in this C program,
> or any of the library functions within the call path, then this particular
> program is exploitable.
Sure. But those are fixable problems. Providing access to a full fledged
Unix shell creates unfixable problems. From a security standpoint there
is a difference between something that is fixable, and something that
is not even theoretically fixable.
Eventually we would close all the holes. And since I am thinking of an
extremely small "language" I don't think that will take very long.
> Why would you create "yet another method of accessing a service/machine"?
Because the average CVS script does almost nothing, they all do pretty
much the same thing, and they represent 99% of the risk of using CVS.
All CVS scripts ever do is grep, send some mail, log to a file,
and return true or false. I think you could get quite far by allowing
all the CVS script files to access the following built-ins, rather
than be shell scripts:
grep -- return true or false by running a regx across the input,
also set $1, $2, etc.
exec -- run one of a predefined list of programs, sudo-style,
test -- compare variables
if -- followed by grep, exec, or test and some action
exit -- quit the script returning success or failure
mail -- send an email, having access to values extracted by grep
and some predefined stuff
log -- like mail, only send text to a predefined logfile instead.
So this is not a turing complete language. It is essentially a restricted
shell, only it is so restricted that many would not call it a shell.
I would bet there's something out there already you could just use.
The exec() would be disabled by default since it would have a null list
of commands to run. I'd also run the exec chrooted and possibly in a
(less) restricted shell as well--though that ought to be a configuration
option. Also the configuration ought not to be in the repository.
All of the above is just as applicable to an ssh-based CVS where you
don't completely trust your clients as it is to pserver.
> In other words, why was pserver invented?
You know what? It doesn't matter. It was created, and it is widely used
now, and it's the only thing that many clients can use easily. It doesn't
matter at this point why that is, because that's enough to mean that I
have no choice about using it.
> Unless this implementation includes some form of *real*
> authentication and integrity of the connection, I fail to see how it will
> be "better" than crappy old pserver... It will be redundant.
Well then the word "fail" is really appropriate because it's been
explained several times.
The choice offered here is not "pserver or ssh?" the choice here is
between "really insecure pserver or somewhat secure pserver?". SSH is
not yet an option. When it is an option I will stop using pserver
because clearly SSH is more secure.
But right now it's not a choice, and I want pserver to be as secure
as it can be while I wait for the clients to catch up.
> Why were these not implemented on the client side? I figure it
> has something to do with the path of least resistance.
That's probably true, but guess what? I need my project to move forward
right now, today. I can't sacrifice the last three years of my work as some
kind of noble gesture to the security of the whole internet in some kind
of abstract and philosophical sense.
I will use SSH or whatever viable alternative appears just as soon as
it is viable. Until now and then I don't see why I should have to use a
totally insecure pserver when it's possible with a very small patch to
have one that is somewhat secure.
> I'm a hardliner, and am going to say "down with inferior protocols".
Then you don't have any business need at stake and you should be ignored.
> I'd love to get one question answered by the *CVS (WinCVS, etc) folks.
> Why is SSH (or SRP, etc) support not built into the core functionality
> of your systems, should your platform/system not give native support?
As soon as it's no more work for my clients to use ssh with WinCVS than
it is to use pserver, I will drop pserver.
Justin
