[Ecls-list] Kamen Lisp update, questions

[Dustin Long]

Faré wrote:
> Note that function calls are not the only potential threats.
> * Modifying some internal variables can be help circumvent security
>   
This is why I thought it better to use a variable on the C side to 
control the security. Without a corresponding lisp symbol, client code 
has no access to it. Or is there something I'm missing here?
> * Accessing memory directly can circumvent security (can an (optimize
> (speed 3) (safety 0)) allow array overflow?)
>   
This I hadn't considered. I've tried testing it in ECL but couldn't 
succeed. Maybe ECL doesn't implement unsafe arrays?

On the other hand, I was under the impression that using si_safe_eval 
sidesteps this. As far as my knowledge went, it only interprets the 
code, and therefore won't optimize it all the way. I know, at the least, 
si_safe_eval won't run clines or c-inline as they need to be compiled.
> * many, many internal functions may be security threats.
>   
Do you have any examples besides the ones I mentioned? Is there anything 
specific to be worried about besides file system access, environmental 
variables, running external programs, and other interactions with the OS?
> * any kind of extension created after your audit, or implicitly loaded
> without your knowledge, can be unsafe.
>   
What do you mean by extensions? I'm guessing you don't mean Firefox 
extensions but extensions to lisp. This is why I made "load" checked 
also, so that no one could, for example, load "sockets.fas".
> * If any function entered from within "secure mode" can somehow
> locally disable it, or schedule actions that will be executed out of
> it, then any callbacks from it, including from handler-binds,
> redefined functions, special variables, etc., are a security threat.
>   
Another good point! Is there a way to execute a form after a time delay, 
like javascript's setTimeout? I've never heard of anything like that in 
cl, but if it's there it's a problem as well.
> Security is very hard (though possible) to add after-the-fact. I hope
> you manage to do it -- but you'll have to maintain your own ECL branch
> to ensure that all extensions are audited at all times.
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Thanks for giving me more to ponder,

Dustin