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:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to