browser execution

marca@ncsa.uiuc.edu (Marc Andreessen)
Date: Tue, 29 Jun 93 02:02:20 -0500
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-id: <9306290702.AA24314@wintermute.ncsa.uiuc.edu>
To: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
Cc: www-talk@nxoc01.cern.ch
Subject: browser execution
In-reply-to: <21669.741272749@moose.cs.indiana.edu>
References: <21669.741272749@moose.cs.indiana.edu>
X-Md4-Signature: fad2e018398d81cc34a5a9def1f694e0
> >Servers are not _that_ easy to write.  They are if you're running UNIX
> >and you have either inetd.conf privileges or know how to do sockets.
> >Who knows what you'd have to do under VMS or MVS and you just can't
> >do them under MS-DOS.  On the other hand, writing a program which
> >dumps some HTML to a file is easy and possible under all systems.
> >It's very similar to adding to a server, but anybody, not just the
> >server administrator can do it and they can share with other non-privileged
> >users.

As a side note, xinetd -- recently posted to comp.sources.unix
-- allows users to run a (turbocharged version of) inetd
without root privileges.

> >Even if you can easily run a server, you've got some security problems
> >to deal with.  Having a browser that will execute code (or URLs, whatever)
> >from documents is a little scary; having a server that anyone can
> >connect to execute code is really scary.  With the browser executing
> >code you leverage off the normal system authentication.  With a server,
> >you have to re-invent that.  Sure, these features are coming and
> >that's good; but you're building up an awful lot of stuff to solve
> >a simple problem.
> 
> Servers can run without privilige; ours runs as id "daemon" and
> doesn't have the priv to do much other than dequeue other people's
> print jobs.  Surely webmasters don't run their HTTP server as root?
> 
> Browsers, on the other hand, have to run as users and are thus capable
> of harming their users; I find using "normal system authentication"
> (as it exists on most machines) to run code in this kind of situation
> highly undesirable.

Having browsers execute code is *very* scary.  Servers generally run
(or should run -- no reason not to) as userid 'nobody', and as such
can cause practically no damage to anything.  In any case, server
writers have much more knowledge about what's going to happen and what
could happen while writing a server than client users do while just
randomly clicking hyperlinks.  I don't see as there's any reason to
think that client-side execution is safer.

> >Well, if you want to add features you have a choice.  Either make it
> >harder for the browser writers or make it harder for the server writers.
> >I maintain that the exec: URL scheme makes it a little harder for
> >the browser writers but is a boon for server writers since it truly
> >makes it easy to write a server (just like the simple inetd scripts,
> >but you don't need privilege).
> 
> Except that what has been written isn't a server at all, it's just a
> program.  It doens't provide a service to anyone except the person (or
> small group of people) who have examined it, decided it safe, and
> placed it on their list of commands for which exec:ing is permissible.
> (unless this procedure is not used, in which case it's a security hole
> you could drive an aircraft carrier through.)

What he said.

Marc