World: r3wp

unprotect: :none
:-)

something to add to R3... proper sandboxing of I/O.

good trick for some cases, but then you can't legitimately unprotect 
stuff while debugging...

Thats the other thing. IMHO modules go not far enough. For frameworks 
i want complete sandboxing of user-code, including quotas. Modules 
go not far enough. For libraries i am worried modules make large 
amounts of code to easy to write (only a little bit worried, or maybe 
just paranoia?).

The issues you are touching on  are all easily circumvented.

If I have your *source* I can easily preprocess it before DOing or 
LOADing it to make whatever behaviour changes I like.

That makes it impossible in a source-level library to get total protection.
Binary modules, that's another issue.
Paranoia is good!

Currently i thnik about including a web-server and use cgis which 
call cgis. then i have no need open things up later, just close them 
enough, do job, exit.

but sunanda, are you going to verify code like glayout (150kb of 
ugly code) for each subrelease ?  not talking about bad intent.. 
just possible dangerous bugs.

Sunanda, its about the protection of the loader, not the loaded IMHO. 
The loader should be able to protect the exe before doing untrusted 
code, and unprotect it later ("shoudl" as in "thats a wish.")

Yep, that bugs are a problem, not only intent. If i have a daemon 
24/7, add a feature which bugs 2 hours later, when i am away, and 
i am bag tomorrow, with the daemon down, thats uncool.

and with harmfull intent... REBOL being what it is, its very easy 
to hide nasty stuff inside obscure code, building up words on the 
fly and setting them from the value of another word ... bla bla.. 
all that stuff is almost impossible to catch with scripts and if 
its nested within similar code, you'll just breeze through it when 
scanning the whole.

cgi-servers can handle this to some extend, but cgi is cgi and not 
chat-speed.

Volker. That's true (and I've said it myself too: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlMGVC
)
But we need to protect "my" library against your loader too.
That's a separate problem.

can you imagine that not being able to know the current login name 
is case enough for REBOL not being used in multiuser office environments. 
 that is something which MUST be addressed in R3 its a simple call 
to the socket lib (IIRC) and if protected, then that info can force 
apps into being multi-user oriented.

I am not sure i like DRM. But i agree on the "separate problem".

right now, its all kludge, hell even the install dirs and setups 
are not consistent between my two machines installed the very same 
way  :-(

WIndows does not store the name in a user-var?

environment vars are not secure in any way or fashion.

But the machine running your scripts can be trusted?

Script to implement a sandbox:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlDGDS
No idea if it works ot how easy it is to cirumvent.
But maybe it could be used to prototype modules.

The machine is trusted, but can you trust the user running it?

still possible to DOS (infinite loop, memory). functions have extra 
features important here, 'first can access function-bodies. Hard 
to think of everything. Would not expose inbuild functions currently. 
For self-written ones it should work. Except that 'load automatically 
creates globally bound funtions, which needs deeper analysis.

Maxim: No, but if i cant trust the user, can i trust the machine? 
But i guess for most uses yes. Could be a nice feature in R3, possible 
in combination with rebservices. Currently, could such things be 
done with 'call?

only admin level users can really do anything to spoof networking... 
normal unpriviledged users cannot change system files, thus cannot 
change libs.

If you can trust the os *flamewar on* ;)

its possible some things can be done with call... but its tedious 
in any case, and not very cross-platform.

But i guess normal users can easier change env-vars somewhere then 
hack the machine.

now if we all where on Amiga who would care... right?   hehe

just run a batch script with set VARNAME VALUE  before your command...

A thing i use personally is
  join read dns:// what-dir

Not for security, but to keep my configurations apart. But maybe 
it helps here?

Hmm, only if you can make sure only the right user can use the script.

create a file and check ownership? does get-modes tell?

On Amiga i could run 50 full-os sandboxes today, solving that problem 
:)

yeah...  plus not having a user name solves that issue on Amiga ;-)

MY kindergarden would surely have labels on the sandboxes!

user-name - how about usingsome password instead and store it somewhere 
user-only? Thats the way ssh etc do it.

now tell your IT manager or CTO that you have to do all of this just 
to get the user name and that you really want to use REBOL...  ;-)

i guess real user-name could be a cross-platform-problem. Specially 
on amiga ;)

Call it cookies?

Add some coffee and cake .. ;)

LOL

Playing marketing, would it helpto add browser-access too? Then that 
cookies could be a good idea. If you do not tell that all that web-interfacing 
is a quic workaround around not having user-names.. :)

It has just occured to me that if REBOL needs a niche and actually 
wants to have REBOL work in the Large... that they need to do only 
one thing.   Embrace XML.   its got everything going for it, there 
is nothing to invent (just read specs and implement, like protocol 
RFCs).

REBOL should not use XML internally, but should be made to be as 
XML literate as is possible.  imagine if we could simply tell any 
current IT management that all they need to USE all of that $ they 
invested in those obscure tools, is Load and then they can actually 
do stuff with it.

just like we just SEND a mail, READ a web site, or WRITE an ftp server. 
 if we could also LOAD/SAVE any XML technologies (XML files, DTDs, 
Schemas, etc), then R3 would immediately get appeal in the corporate 
world.  It would actually have value to them .

I agree. That's a good thought.

And R3 would have the excuse of being able to be IT friendly.. which 
it currently isn't.   AND it would benefit of having access to a 
slew of tools which actually help some people get work done integrating 
Heterogenous systems, which is something REBOL is currently incapable 
of stating.

If you get any salesman in an IT dept which has XML capabilities 
(and they are getting used, really) and in 15 minutes, LOADS their 
data structures, instances, edits them and spits them right back 
out using a simple command line interface... welll...  case closed.

you at least get a chance at having REBOL being used for some little 
tidbits, and as we all know, it will become addictive and soon will 
get used more and more.

corporate environments, big or small, need liabilities, assurance, 
and REBOL is sooo scary right now, most people just say...

nice toy!