Shared address space and trust and what is a "user" [Re: Our Manifesto (Please Read)]

[David Gadbois]

   From: someone who has a really wacky MUA
   Date: Wed, 07 May 1997 19:41:22 -0500

   This again brings up a topic that came up briefly with Mike in
   private mail.

   In today's Internet environment, you really can't run services on a
   system in which the server code has access to the full system
   because the risk of security bugs is so great.  If LispMs had
   become as popular as Unix systems have become, the problem with
   viruses and hackers would be far worse than it it.

   I'm entirely underqualified to solve the issues involved, but
   someone needs to think about how we either isolate different users
   in the same address space or how we pass objects between processes
   running as different users.

I think these cheap, coarse-granularity tricks like separate address
spaces, user-level authentication, and setuid bits are highly
overrated.  They give a misleading appearance of security without
actually doing much to actually improve it.

I will argue against them, and for a flexible single address space
system, on several fronts:

o Non-solutions for non-problems.  Separate address spaces save you
from problems like application scribbling over memory, buffer
overruns, stack-smashing attacks, and so forth.  You just don't have
these problems in Lisp.

o Only a partially solution to a system problem.  Separate address
spaces allow for containment of problems (when you don't go to usual
efforts you have to do to get around their restrictions), but real
security involves authentications, auditing, access-control, and a
bunch of other things, and separate addresses space only restrict a
real architecture for dealing with all of them.

o Papering over the lack of real services.  Not to UNIX-bash too much,
but, with all the services you want being just a function call away,
you don't have to take the security risks engendered by having to fire
up some gargantuan, incomprehensible, command-interpreting separate
program in order to obtain the simplest of effects.  Instead, you just
use exactly the code you want, and that code is easily auditable for
security.

o "User"-level authentication is ancient technology.  I mean, who
cares about J. Random Luser sitting in front of his Windows box.  The
action is going to be in dealing with security, authentication, and
access control for all the purpose-driven agents doing stuff for him.

o The rest of the world.  From what little I understand of the
existing security systems used by the folks who really care about it
(the financial industry, the military, and the spooks), they are
totally incompatible with remote-point user authentication.  And that
is exactly where some really big, unexplored wins are:  the big-iron
folks are just now getting into the '80s, and they are some great
market opportunities there.

o Hack value.  Frankly, I like that giddy, naughty feeling you get
when you set RPC::*UNIX-CHECK-PASSWORD-FOR-SHOW* to NIL in Genera.
(It basically has the OS tell remote RPC servers yessir, I have
authenticated that user, sure I have.)

o Experience.  I have been managing Lisp- and UNIX-based systems for
years.  I can tell you that it is vastly easier to obtain a level of
security confidence in Lisp-based systems than in UNIX ones.  I still
have nightmares about sendmail vulnerabilities, whereas a CL-HTTP
security audit takes just a few hours.

About all I can think of positive to say about separate address
spaces is that they are an element of defense-in-depth.

--David Gadbois