Re: Lisp security

John Thingstad wrote:
Obviously Lisp is not prone to buffer overfow controls. (unless optimations turn bounds checking off)
But there is the question of Java.final.
Apperaently there is no equivalence in Lisp.
Simularly there is the possibility to change inheritance after runtime.
Also decaring code after runtime.
Obviously if you get trough the outer defenses Lisp is chanseless.
Any chance of anyone (Allegro) deveoping a 'sandbox' for lisp?

This will probably take a lot of work because there are a lot of potential security holes. (Think about (setf symbol-function).)

Dylan has a notion of sealed generic functions and sealed classes which could be useful here. However, an all-or-nothing approach is also not quite right. You probably want a more fine-grained approach which allows you to give different parts of a program different "rights" or capabilities.

We are actually thinking about using something like ContextL to grant rights for some code in a certain context (and disallow changing the rights for that context at the same time). However, this is no more than a vague idea by now, there is probably a lot of work to be done to make this work.


Pascal

--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
.

Relevant Pages

  • Re: Thread-safe caches
    ... multiple processor cache implementations. ... Under the current Lisp technologies, you are not likely to see ... I think I have been able to solve the concrete problem I had in ContextL. ...
    (comp.lang.lisp)
  • Re: We are happy to announce: our first Lisp production system went online
    ... We use the following Common Lisp libraries. ... Closer to MOP & ContextL: http://common-lisp.net/project/closer/ ...
    (comp.lang.lisp)
  • Re: Lots of new (incompatible) Lisp dialects
    ... than the ones we already have (Common Lisp, Scheme, ISLISP, Dylan and some others). ... I don't see a value in new Lisp dialects that are only better at such superficial levels. ... What's even worse is that these new Lisp dialects are typically implemented from scratch, which means that decades of experience with efficient implementation techniques are lost and have to rediscovered. ... Closer to MOP & ContextL: http://common-lisp.net/project/closer/ ...
    (comp.lang.lisp)
  • Martin Fowler...
    ... but I think the explanation is very much to the point. ... Sidenote: Yes, it's not really about Lisp. ... Closer to MOP & ContextL: http://common-lisp.net/project/closer/ ...
    (comp.lang.lisp)