RE: Another use for Guile/Scheme/Lisp

["Redford, John" <John.Redford@fmr.com>]

> From:	Tel [SMTP:telford@eng.uts.edu.au]
> 
> Maybe scheme would make a good language for sending little applications
> to web browsers to allow interactive web pages. It just requires that
> every web browser has a scheme interpreter in it (probably should start
> with lynx). A good name might be ``scemava''!
> 
> > In addition, other possibilties are: that a program could move its whole
> > self for execution on a different system as it needed different
> > resources, etc.  Of course issues like these need security measures,
> > but with certificates, encryption and such this type of communications
> > could be made secure.
> 
> ``scheme-o-wolf'' <grin>
> 
> One idea for security is to have a C global variable in the interpreter
> that contains security bits for various operations (opening files, opening
> sockets, looking at directories, etc). All of the sensitive primitives
> would check their bits before executing. Only one primitive can change
> bits and it always clears some bits, then evals a lambda then sets
> the bits again (so you can give up abilities but not gain new abilities).
> It would be a bit of a pain putting all the security checks into the
> primitives but it would be secure.
> 
> One problem with scheme is that there is no way of protecting memory
> in the case of a type conversion bug. For example, if the user figures out
> a way of converting an integer to a pointer then anything in the
> interpreter
> image can be trashed (or modified to duplicate higher privileges).
> Theoretically this is impossible but bugs will happen. I guess it's better
> to fix the bugs than worry about what might happen if they were there...
> 
> 	- Tel
> 
I think there are important reasons to not use a model which depends on
"security bits". I think this is somewhat outside of the scope of this
mailing list, but worth stating once, for the benefit of the people who
don't get a chance to read the papers I mentioned before.

Security bits can be overloaded and incomplete.
   Consider the problem of a Unix file which is executable, but not
readable.
Security bits occupy space.
  Often they occupy fixed spaces, which mean that new bits cannot be added,
and so the 't' bit winds up with 3 or 4 meanings, because they couldn't just
add a new bit for each security relation.
  Those spaces need to be small, even when they are not fixed, because...
Security bits occupy time.
  Every primitive needs to check relevant security flags. This impacts the
performance of those functions.
Security bits embed security into functionality.
  When a primitive contains code for security, the security is hard-wired
into the functionality. At the same time, security policy as a whole is
indeterminate, because it is not collected in a single location.
Security bits are atomic.
  If there is a bit which controls a given action, that action cannot later
be broken into parts, with each governed by a distinct security control.
(Not without creating a potential paradox, where a user has access to every
step of an action, but not to the action itself.)

There are other reasons as well. Security bits are a form of "security by
obscurity". Instead of limiting a users ability to access Foo(), you limit
his ability to access the bit which controls Foo(). This is not a
substantive benefit, just an indirection.

Again, I would strongly encourage people to read the DEC SRC report 122. It
is available from DEC's website. Follow the "research" related links.

--
John Redford
AKA GArrow