[Ecls-list] Kamen Lisp update, questions

[Faré]

Note that function calls are not the only potential threats.
* Modifying some internal variables can be help circumvent security
* Accessing memory directly can circumvent security (can an (optimize
(speed 3) (safety 0)) allow array overflow?)
* many, many internal functions may be security threats.
* any kind of extension created after your audit, or implicitly loaded
without your knowledge, can be unsafe.
* 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.

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 ]
Chuangtse and Hueitse had strolled onto the bridge over the Hao,
when the former observed, ``See how the small fish are darting about!
That is the happiness of the fish.'' ``You are not a fish yourself,''
said Hueitse. ``How can you know the happiness of the fish?'' ``And you
not being I,'' retorted Chuangtse, ``how can you know that I do not know?''
                -- Chuangtse, circa 300 B.C.


> 2) I threw in a basic security model. It works by wrapping each
> interpretation of a webpage's lisp code in a new symbol
> "ext:call-secure", which is a function taking a zero-arg lambda
> expression. When it runs that lambda, no call to a "sensitive" operation
> is allowed. The custom ECL build was also modified for this: sensitive
> operations call the function "ext:security-check", which signals an
> error if it is within "ext:call-secure". The following functions are
> treated as sensitive: open, load, quit, truename, rename-file,
> delete-file, probe-file, file-write-date, file-author, directory,
> si:chdir, si:mkdir, si:rmdir, si:system, si:getpid, si:open-pipe,
> si:run-program.

> Now I have some questions, if I may:
>
> 1) For the security model, are there any other dangerous symbols I
> missed? I know there's at least a few I noticed at the last minute but
> forgot to include. But I'd like to make sure I get them for in the next
> release.