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

[Chris Bitmead uid(x22068)]

>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.

You don't have these problems with a real lisp machine. I'm not sure
about stock hardware though. Either the virtual machine will have to
be like Java and be very careful about things (slower perhaps?), or if
using native binaries.... I don't know. You would have to have a
compiler that you know you trust, and you would have to know that only
trusted compilers can make binaries. Further, you would have to have
some impossible to break crypto/checksum to make sure hackers don't
hand-assemble a program. And then whenever you run something in native
code, you would have to read the whole thing into memory and do a
check-sum to make sure it was produced by a safe compiler.

Perhaps these things are possible, but they scare me. I have these gut
feelings that someone will get around them.

But concerning address spaces...

I think I agree that everything should run in the same address space,
if by that you mean that pointer 0x12312456 in thread or program "a",
should be pointing to the same object inside of thread "b".

But I do think we should use the MMU of modern computer chips to
prevent different lisp processes from trampling over objects that they
don't have permission to. Lisp processes will still often have shared
objects. It's just that some programs would be able to keep themselves
and their data secure by using MMU protection.

I can't see any down-side to putting in this extra level of safety,
but perhaps someone else can. It does perhaps bring to my mind the
relative advantages and disadvantages of object vs page level
granularity though. Perhaps this will be the cause of problems.

>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.

Are you talking about separate address spaces, or MMU memory
protection?

>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.

What exactly do you mean by user-level auth? I would have thought that
most security issues eventually come down to which user asked for a
particular service.

Assuming MMU safety is considered a good thing, you would need a way
to specify some Lisp functions as "secure" so that they run with a
different level of MMU protection. (I was going to say run in a
different address space, but I don't want to confuse the two issues).