World: r3wp

.

This group is for proposing new stuff for REBOL 3, and then discussing 
these proposals. In general these proposals will be about changes 
to R3 itself, but many may end up being third-party extensions instead. 
Don't be shy!

Can this be [web-public] -- that may help REBOL Advocacy.

of course!

(And keep things civil) :)

I ask because most REBOL3 groups are not.

Thanks......I'll take those two responses as permission to do it....

First proposal (by Sunanda, copied from some other group): SECURE/do 
block!


SECURE/do would take a block of code to do in a different set of 
security constraints, and then return the security constraints to 
what they were before upon the return of the function. If the security 
constraints are more relaxed then the user would have to be asked, 
or whatever the security settings are. If they are more constrained, 
the user won't have to be asked. And the user won't be asked upon 
returning the constraints to their previous setting when SECURE/do 
returns - this is the whole point to the proposal.


SECURE/do would need to be task-local because its scope would be 
calling and returning from a function, a task-local operation.

The downside to SECURE/do is that it could be used to make state 
changes that could affect later code after the security settings 
are returned to their prior values. It is not full sandboxing.

Thanks Brian.....But credit yourself and Maxim for refining it to 
something that may be implementable.

brian, the only way I can see this is if the executed code didn't 
catch something and we unwind past the SECURE and it never gets a 
chance to restore the state.

Maxim and I made some tweaks to Sunanda's proposal. Those tweaks 
were discussed in Core, but here are the basics:

- Making this an option to SECURE rather than DO is simpler (DO is 
hybrid, SECURE is full mezz) and more secure (only SECURE would need 
access to the internal stuff).

- Doing this as an explicit stack (SECURE/push and SECURE/pop) would 
not allow us to pop without asking the user for permission.

thus, SECURE should (always?)  wrap the execution within what ever 
becomes the sandbox.

alternatively, it could a feature of the sandbox model...

SANDBOX/secure

I prefer this later idea.

It would be better to put this in SECURE itself because of the internal 
stuff that SECURE needs to access. We couldn't edit or replace SANDBOX 
if we did this there directly.

SANDBOX needs to be developer-replacable, because what needs sandboxing 
will vary from app to app.

ok... but when does the pop up occur?  it seems to me like they are 
managed directly within the SET-POLICIES native function.

The pop occurs when SECURE/do returns.

The internal functions will need tweaking to make this possible, 
of course. At the very least they will need to be made task-local.

looking more closely at the source it seems like make-policy is the 
only internal function being used in secure... am I right?

Don't know, it's been a while. I can't implement this today - it's 
a busy week.

ok, so maybe the system/state/policies could have a companion which 
is a stack of the current policies at each step of secure/do.

(looking at old R3 the policies may have moved)

You can store that stack as local variables in the SECURE mezz, manually 
restoring them when the /do is done.

The problem with making running state secure so that functions won't 
be installed when the security restores is that it is much trickier 
to secure task-local state than it is to do for the stuff in lib 
and sys. We should consider doing this as a MAKE task! extension 
instead.

ah... yes... stupid idea on my part... obviously that makes it task 
local by default... doh.

though the MAKE task! is appealing its also very disruptive, since 
it implies a lot more than just securing access to devices.


but I am not sure what you mean by "so that functions won't be installed 
when the security restores"

We can secure lib and sys because we are smart mezzanine developers, 
and they can stay secured. But the user contexts are task-local and 
isolated, so they would need to be secured again for each task. And 
any script you run in a user context affects subsequent scripts run 
in that same context. So if you run a script with increased security, 
it can install functions in the user context that it is running in 
that wouldn't affect the already-secured lib code, but *would* affect 
code that is run in the same user context after SECURE/do returns. 
So if those functions are called later, they will run with full permissions. 
This is called escalation.

yes... I just wanted to be sure that is what you meant.

But SECURE doesn't protect from those kind of security issues anyways, 
so this may be not a problem that we have to worry about here. However, 
normally the security prompt will protect against this kind of thing, 
and the whole point of SECURE/do is to get rid of that prompt.

though in most cases SECURE/do would be used to restrict what *your* 
code is allowed to access ...

Full sandboxing would require running in a separate task, calling 
a script by IMPORT/no-lib/no-user/isolate instead of DO, and providing 
a whole set of safe words and wrapper functions for the script to 
use. But many aspects of the existing system are designed with this 
in mind.

I think we don't need a separate task for sandboxing... since this 
opens up new different concurency issues.

Total sandboxing might require SECURE/LAUNCH rather than SECURE/DO. 
But that's a whole other set of trade-offs.

We would need eval limits then if you don't do the separate task. 
Do those work yet?

since as part of the new task, there is an implicit "clone-user-context" 
step at some point...   maybe that could be something we can actually 
use manually within a script?

so you clone user context, run stuff inside of it, then pull out 
some expected data changes, and destroy that clone explicitely.

The eval limits I tried work

Um, no, there is no indication that there will be a "clone-user-context" 
step as part of making a new task. There is a "clone the user context 
from the lib" step in starting all user scripts, but no "clone a 
user context from another user context" step.

Everything said about the concurrency model so far indicates that 
it will not be the fork/exec model. Instead it will be the "create 
a new user context from scratch and populate its task-local values 
from the shared stuff" model.

And shared stuff you don't want modified will be made read-only. 
There will likely be some kind of message passing and/or synchronization 
to share modifiable data between tasks and coordinate efforts.

I think that user-context cloning should be considered as an option. 
 even without tasks.  it might help in providing a proper sand-box. 
  though I can see some things that it currently doesn't cover on 
its own, it would allow the basis for a strong model.

something like:

ctx: clone-user-ctx


ctx/my-func data ; (this becomes shared, so you decide how this is 
managed, copy if required)

what I need:  ctx/some-value

ctx: none  ; recycle it.

All you need to do to sandbox some code is isolate it and give it 
its own lib and user contexts.

yes... but "it's own" should allow a clone of the "current" one.

A user context by default only contains a reference to system. Everything 
else comes from lib. Cloning lib is more effective.

I'm not talking about fast, I am talking about easy and practical. 
 the user-context already exists so Cloning it should also be an 
option.

make it lib by default (which I agree it should be) but in many cases, 
that will lead to *very* complicated or even impossible to replicate 
data setups.

shared stuff can be tampered.

when its protected, then it can't be used in all circumstances.


a perfect clone of the user allows tampering, without the danger, 
since it can't affect you anyways.

A standard sandbox lib could be provided that contains a safe version 
of the standard lib that R3 comes with. Then you could derive your 
own safe lib from that one, to add your own predefined functions. 
No clone of the user context would be necessary. And for that matter, 
you should assume that cloning the user context is impossible because 
of cyclic references.

actually, cyclic references is one of the specific reasons for a 
clone-user-context native ! ;-)

The SANDBOX function wouldn't then need to do anything custom to 
the user context that the script it is running is using. All it would 
need to do is create a safe system object, create an object that 
references that object using the 'system word, and set the lib and 
security settings to those provided as arguments to the SANDBOX function.

I agree on all points.