Hi Christophe,
> > Then, the most glaring security risks are the 'call' and 'pipe'
> > functions, and the pipe functionalities of 'in', 'out' and 'load'. They
> > allow a REPL user to directly access the interlying system. If these
> > were disabled (can probably done on the Lisp level in the 'repl'
>
> How would you disable them? Would this be ok?
> (de annihilate @ (mapcar '((sym) (set sym NIL)) (rest)))
> Then call it this way (I think that I understand now why low level functions
> should evaluate their args):
> (annihilate 'call 'pipe ...)
I would not disable them system-wide.
The critical point is only the place where 'eval' is called. I would
change this fragment from the 'repl' function (line 336 in "lib/form.l")
(catch '(NIL)
(let Res (in "/dev/null" (eval (any Str)))
(prin "-> ")
(println Res) ) )
to something like
(catch '(NIL)
(let Res
(in "/dev/null"
(let (call prog load prog in prog out prog pipe prog dir prog)
(eval (any Str)) ) )
(prin "-> ")
(println Res) ) )
Note that this sets these functions to 'prog'. Setting them to NIL like
in your example is also OK, but gives a runtime error, while 'prog'
silently evaluates its arguments and does nothing.
Another option would be not to disable some of these functions
completely, but allow I/O to controlled places. This can be done, for
example, by disallowing list arguments to 'in' and 'out' (they trigger
pipe calls), and checking the path names for allowed ranges.
> This is the delicate/time consuming part: testing, trying to crack a
> «safe» interp.
And this is _always_ possible, I believe. It depends on what you call
"crack", but unless you hamper the language until it is no longer
turing-compatible, an attacker can always create infinite loops or
unlimited recursions and thus seriously disturb the server.
And if you try to control this too (e.g. with a watchdog which kills
such processes), an attacker can still find other ways, like a DoS
attack.
♪♫ Alex
--
UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
