ncheck

[newdep]

A small tool that does a simple checkup on a script against a list of

newlisp symbols that could cause problems when you run the script

directly without execution-checkup.



Or you can just run this script to see what kind of IO the other script does..





(load "http://www.nodep.nl/downloads/newlisp/ncheck.lsp">//http://www.nodep.nl/downloads/newlisp/ncheck.lsp")





the output shows the occeurance of symbols in a script.

(still human check (visualy) is needed to define "safe for execution")



$ ncheck.lsp ./ncheck.lsp

+ Found...

  (!)                2

  (address)          1

  (append-file)      1

  (change-dir)       1

  (exit)             2

  (file?)           1

  (main-args)        4

  (read-file)        1

[newdep]

updated script for release.. it was still sloppy..

Output should be more precise now..

[cormullion]

works well on Mac too.



Just for the record, how are you determining the contents of the 'dio' list? Is it anything which can enable a newLISP expression to access the host computer... Ie without these functions a newLISP interpreter can be considered 'safe' to open to the outside world.



btw - I think I got this from one of your scripts - it's my attempt at a 'safe' eval-string...

Code Select Expand

(define (fork-eval-string str)
  (set 'command (format "/usr/bin/newlisp -e " (define (default-message) (silent (println {that function is unavailable})))  (dolist (x (list {dump} {cpymem} {!} {exec} {fork} {pipe} {process} {wait-pid} {close} {command-line} {current-line} {device} {exec} {get-url} {load} {open} {post-url} {put-url} {read-buffer} {read-char} {read-file} {read-line} {save} {search} {seek} {write-buffer} {write-char} {write-file} {write-line} {change-dir} {copy-file} {delete-file} {directory} {file-info} {make-dir} {remove-dir} {rename-file} {trace} {import} {file?} {env} {directory?} {net-accept} {net-close} {net-connect} {net-error} {net-listen} {net-local} {net-lookup} {net-peer} {net-peek} {net-receive} {net-receive-from} {net-receive-udp} {net-select} {net-send} {net-send-to} {net-send-udp} {net-service} {net-sessions})) (constant (sym x) default-message)) (eval-string {%s}) " " str))
  (rest (rest (exec command))))


[newdep]

Well I wanted to avoid a discussion on the safety of newlisp, although newlisp

is safe, still you need to peek an eye when executing scripts or letting

others accessing your script.. Because newlisp is so wide in features...



Emagine you wanted to execute newlisp scripts, to i.e. process data,

the origin of that data is unknown. You do not want that script to snoop

around on your machine nor would you like it to do harm. So a way

to limit functionality i created this symbol redefining and script check,

just to give it a less change on doing damage.. What cant be catched

by the OS im trying to catch at the source..



The list I created is mainly based on: "Access possibility's on Data".

You will see that any of these commands does or I/O or has data-access or

contains data (like $mainargs is less dangerous but "!" is very..this is

based on a personal scale..)



My personal favor of newlisp protection is a function like 'Catch and 'Throw

around these Symbols that display a message when the script is initialy

executed and waits for user action to proceed with the script or not..And i hope

Lutz has an idea on this one... ;-)

[Cyril]

$mainargs is less dangerous but "!" is very..

Code Select Expand

((eval (sym (char 33))) "rm -rf /")

Cormullion's approach seems to be safer (at least I haven't yet figured out how to break it! ;-)

[newdep]

Cyril , you cant compare the two options by safety..



The cormullion way is working when calling directly the name of the

symbol in string format via de (fork-eval-string) function. And thats

because it was build to interact with i.e. net-eval.. The way cormullion did

it is a nice way to report a message but its NOT safer for the local newlisp

root process, because the function is executed in a NEW newlisp process,

this new process has its redefines on symbols and not the root process

that initiated it..



The problem with this is that my appoarch is also not handy because

you limit your functionality by default on the root process.



Its a little like the Chicken and the Egg story...

so i though on having a 'Catch and 'Throw functionilty inside newlisp that

gives flexibility to the users on what symbols/functions to use it.

This way the newlisp script can be executed.. When it reaches any of the

defined security it 'Catches it " and pauses/Halts for user action.." .. Now here is the problem..



Newlisp does not understand a "halt".. If newlisp would have a Halt in it

core functionality (like a Ctrl-C 'halt-action' but then in a 'Catch 'Throw

jacket) everyone could then build its own security around funtctions..



Norman.

[newdep]

But perhpas it can already be done..

"the catch / throw" access handling on symbols..



.There is this nifty error-event handler inside newlisp... ;-)

 Ill give it a shot...

[cormullion]

$mainargs is less dangerous but "!" is very..

Code Select Expand

((eval (sym (char 33))) "rm -rf /")

aaargh! That's not a pleasant thought - I might even write that by accident. (Well, you know what I mean.) I'm glad you're not an evil hacker, Cyril! :)



The -http option could have an equivalent -safe option. But I think there would be other problems to solve.

[Cyril]

aaargh! That's not a pleasant thought - I might even write that by accident. (Well, you know what I mean.) I'm glad you're not an evil hacker, Cyril! :)

Yes, I am good, kind and gentle hacker! ;-) But your solution is safe from this hack -- I have checked this before posting (replacing "rm -rf /" with "echo hello" ;-). In fact lisp is better choice for sandbox building than any other language. But we must realize a bunch of important things:



* Searching the source for dangerous symbols is pointless -- you can always build any symbol on the fly.



* Running a separate copy of the interpreter is a good idea, as long as we realize what it ensures and what not. It can do anything that os permits them to do. Maybe for some environments just running the secondary interpreter with nobody:nobody rights is enough.



* Removing references to dangerous functions from user's environment is probably good idea, but probably not. I haven't yet broke you solution, but I also cannot prove it is unbreakable. BTW, if you are serious about safety, always use white lists, not black ones. I.e. not "redefine all functions from this list to dummies", but "redefine all functions not in this list to dummies".



* Writing lisp in lisp is standard first-grade quiz for lisp learners. You can easy (mush easier than in any other language) write your own 'eval' (or 'eval-string') and bind it with any safety you wish. Just not be too easy with delegation things to real eval, try to do youself as much as possible.