SDK licensing issues
[1/21] from: lmecir:mbox:vol:cz at: 2-Feb-2006 10:17
see http://www.compkarori.com/vanilla/display/SDK+and+exporting+the+API
for an interesting discussion
-L
[2/21] from: SunandaDH:aol at: 2-Feb-2006 4:41
Ladislav:
> an interesting discussion
Thanks. It is.
I once toyed with the idea of allowing Library members to upload arbitrary
code that REBOL.org would execute on their behalf.
The theory being that it would allow the ultimate level in customization of
the services the Library provides -- instead of being limited to the preference
checkboxes on configuration panels, your arbitrary code could filter or
enhance the stuff the CGI scripts produce.
The idea got put aside for two reasons. One was the licensing -- which
appears now to be a resolved issue.
The other was (as Carl exactly puts it in the dialog you've pointed us to)
Ah... That's really dangerous.
We would need to ensure that any arbitrary code had no access to all sorts of
things that a stand-alone REBOL script can do. One worse-case scenario is
that a spammer writes a script that sends a bazillion emails and we run it for
them.
Running arbitrary code safely requires more than a sandbox: more of a
blast-proof bunker.
Some parts of such a bunker can be constructed by unsetting or modifying
mezzanines (disabling send is an easy one).
But other parts are not so easy -- how to stop a script overwriting part of
the system object, or running for more than 1 second, or writing more files
than we have a quota for?
That level of security needs some support at the built-in / native level.
Sunanda
[3/21] from: carl:cybercraft at: 2-Feb-2006 12:27
On Thursday, 2-February-2006 at 4:41:45 SunandaDH wrote,
>Ladislav:
>> an interesting discussion
<<quoted lines omitted: 6>>
>checkboxes on configuration panels, your arbitrary code could filter or
>enhance the stuff the CGI scripts produce.
Isn't that a job for a dialect? One written with security in mind?
-- Carl Read.
[4/21] from: sqlab:gmx at: 2-Feb-2006 11:32
How about a load/secure level ?
where level none just does not allow the usage of /pro or /command
functions,
higher levels could prohibit more functions
USAGE:
LOAD source /header /next /library /markup /all /secure level
DESCRIPTION:
Loads a file, URL, or string. Binds words to global context.
LOAD is a native value.
ARGUMENTS:
source -- (Type: file url string any-block binary)
REFINEMENTS:
/header -- Includes REBOL header object if present.
/next -- Load the next value only. Return block with value and new
position.
/library -- Force file to be a dynamic library. (Command version)
/markup -- Convert HTML and XML to a block of tags and strings.
/all -- Load all values. Does not evaluate REBOL header.
/secure -- prohibits unsafe and not allowed functions
level -- security level (Type: none block)
>>
SunandaDH-aol.com wrote:
[5/21] from: charles:mougel:spinodo at: 20-Jan-2006 11:55
sqlab a =E9crit :
>How about a load/secure level ?
>where level none just does not allow the usage of /pro or /command
>functions,
>higher levels could prohibit more functions
>
I think the same.
I, as a developer, I don't want to check what is pro and not. This is a
RT or community job do to it one time.
The idea can be the same for security. There is levels in VM, why not in
an encaped appli which can load script.
This points are interesting, because we can think about updating patchs,
or plugins, for your apps !
The dialect option is a good way, but an other easy way is to crypt scripts.
Charles.
[6/21] from: charles:mougel:spinodo at: 2-Feb-2006 11:57
sqlab a =E9crit :
>How about a load/secure level ?
>where level none just does not allow the usage of /pro or /command
>functions,
>higher levels could prohibit more functions
I think the same.
I, as a developer, I don't want to check what is pro and not. This is a
RT or community job do to it one time.
The idea can be the same for security. There is levels in VM, why not in
an encaped appli which can load script.
This points are interesting, because we can think about updating patchs,
or plugins, for your apps !
The dialect option is a good way, but an other easy way is to crypt scripts.
Charles.
[7/21] from: SunandaDH::aol::com at: 2-Feb-2006 6:00
Carl:
> Isn't that a job for a dialect? One written with security in mind?
There are two possible approaches:
-- a dialect: everything you can't say in the dialect is forbidden
-- a sandbox/bunker: you can say anything you like except what is forbidden
The dialect approach is safer
the sandbox/bunker approach offers (in theory) greater freedom. but at the
risk of missing something crucial and opening a security hole.
REBOL already, in effect, has a built-in bunker -- you are trapped in it
unless you have the magic license key; that opens the door to freedom and the /pro
features.
It would be nice to be able to craft a bunker at the mezzanine level: there'd
be a bunker-defining dialect:
allow [read compose]
disallow [write sound view]
check [send write] ; with a function supplied that does the checking
Sunanda.
[8/21] from: compkarori:gm:ail at: 2-Feb-2006 12:27
Isn't the dialect way forcing you to basically write a Rebol interpreter
when you already have one??
On 2/3/06, SunandaDH-aol.com <SunandaDH-aol.com> wrote:
> Carl:
> > Isn't that a job for a dialect? One written with security in mind?
<<quoted lines omitted: 3>>
> forbidden
> The dialect approach is safer
--
Graham Chiu
http://www.compkarori.com/emr/
[9/21] from: gabriele::colellachiara::com at: 3-Feb-2006 12:43
Hi Graham,
On Thursday, February 2, 2006, 12:10:01 PM, you wrote:
GC> Isn't the dialect way forcing you to basically write a Rebol interpreter
GC> when you already have one??
Why would a *normal* synapse chat user need a REBOL interpreter?
Regards,
Gabriele.
--
Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/
Colella Chiara software division --- http://www.colellachiara.com/
[10/21] from: volker:nitsch:g:mail at: 3-Feb-2006 15:39
On 2/3/06, Gabriele Santilli <gabriele-colellachiara.com> wrote:
> Hi Graham,
>
> On Thursday, February 2, 2006, 12:10:01 PM, you wrote:
>
> GC> Isn't the dialect way forcing you to basically write a Rebol interpreter
> GC> when you already have one??
>
> Why would a *normal* synapse chat user need a REBOL interpreter?
>
To set the username, the color and all such things which are not
menuified or just do not work. :)
Or just to show a bit rebol to the uninitiaded.
Or later to do a quick complex search without need for a fully fledged
dialect first (you know, every sufficiently complex program implements
a lisp-interpreter, sadly even rebol-coders have to do that ;)
Why is it implemented in IOS conference?
> Regards,
> Gabriele.
<<quoted lines omitted: 4>>
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
--
-Volker
Any problem in computer science can be solved with another layer of
indirection. But that usually will create another problem.
David
Wheeler
[11/21] from: greggirwin:mindspring at: 3-Feb-2006 9:13
GS>> Why would a *normal* synapse chat user need a REBOL interpreter?
VN> Or later to do a quick complex search without need for a fully fledged
VN> dialect first (you know, every sufficiently complex program implements
VN> a lisp-interpreter, sadly even rebol-coders have to do that ;)
This is one of those wonderful, tricky areas that we don't know much
about yet (IMO); how do we write applications that can safely use
REBOL as their macro language.
We can be safe by writing a dialect, but that's a lot of work if we
want a powerful macro language, and you may still open up security
holes (probably will as a matter of fact).
You can't be safe running raw REBOL; even a macro the user writes is
unsafe because it can unintentionally cause harm. Of course, if the
macro code has access to application code, all bets are off about
whether the app will even run.
The allure of configurable apps, with REBOL as a macro language, is
powerful; but danger doesn't lurk there, it's in plain sight.
-- Gregg
[12/21] from: volker:nitsch::gmail at: 3-Feb-2006 20:33
On 2/3/06, Gregg Irwin <greggirwin-mindspring.com> wrote:
> GS>> Why would a *normal* synapse chat user need a REBOL interpreter?
> VN> Or later to do a quick complex search without need for a fully fledged
<<quoted lines omitted: 12>>
> The allure of configurable apps, with REBOL as a macro language, is
> powerful; but danger doesn't lurk there, it's in plain sight.
MS uses VB for user-scripting all the time. With regard to internet
dangerous, yes. But for a big part because VB cant lock system-access,
while 'secure can. With rebol a macro can only harm the application,
in VB take over the system. Thats different. Althought 'secure could
use improvements, specially restricting network better (to certain
hosts/ports only, currently it can play proxy to the internal
network). And needs better explanation.
> -- Gregg
>
> --
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
>
--
-Volker
Any problem in computer science can be solved with another layer of
indirection. But that usually will create another problem.
David
Wheeler
[13/21] from: greggirwin:mindspring at: 3-Feb-2006 12:55
Hi Volker,
VN> MS uses VB for user-scripting all the time. With regard to internet
VN> dangerous, yes. But for a big part because VB cant lock system-access,
VN> while 'secure can. With rebol a macro can only harm the application,
VN> in VB take over the system. Thats different. Althought 'secure could
VN> use improvements, specially restricting network better (to certain
VN> hosts/ports only, currently it can play proxy to the internal
VN> network). And needs better explanation.
Yup. The main thing is to understand what can happen and structure
things accordingly. e.g. can a user trigger an error to bring up a
console and see all the internals of an encapped app, etc.
-- Gregg
[14/21] from: volker::nitsch::gmail::com at: 3-Feb-2006 21:18
On 2/3/06, Gregg Irwin <greggirwin-mindspring.com> wrote:
> Hi Volker,
> VN> MS uses VB for user-scripting all the time. With regard to internet
<<quoted lines omitted: 7>>
> things accordingly. e.g. can a user trigger an error to bring up a
> console and see all the internals of an encapped app, etc.
Ah, that! I thought "cause harm" like a virus, not like seing the source.
> -- Gregg
>
> --
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
>
--
-Volker
Any problem in computer science can be solved with another layer of
indirection. But that usually will create another problem.
David
Wheeler
[15/21] from: anton::wilddsl::net::au at: 4-Feb-2006 15:48
Well, I would say the spammer would simply reimplement
any functions which were unset, so, yes, we would need
to be able to lock parts of the system.
A firewall type ability would be good.
Only allow outgoing connections on http port 80 ?
That would stop any mail sending.
Anton.
[16/21] from: gabriele:colellachiara at: 4-Feb-2006 18:03
Hi Volker,
On Friday, February 3, 2006, 3:39:08 PM, you wrote:
VN> To set the username, the color and all such things which are not
VN> menuified or just do not work. :)
A normal user can do that? You surely mean a reboler. A reboler
just runs it in View.
VN> Why is it implemented in IOS conference?
Because that is not subject to the SDK license, because IOS is a
closed system, and because Link already executes any code you give
it like View.
Oh, and btw, the version of conference that did that was only made
available to REBOL Developers... :)
Regards,
Gabriele.
--
Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/
Colella Chiara software division --- http://www.colellachiara.com/
[17/21] from: SunandaDH:aol at: 5-Feb-2006 5:08
Anton:
> That would stop any mail sending.
That solves one problem, but requires third-party software to keep REBOL safe.
And, as Gregg says:
> The allure of configurable apps, with REBOL as a macro language, is
> powerful; but danger doesn't lurk there, it's in plain sight.
How could we safely run *any* REBOL script as a macro language without it
doing damage?
I don't think there is a simply answer to that, and any answer will need RT's
involvement. But here is one possibility
RT create (yet another) REBOL executable called (say) REBOL/Macro.
That contains generally thought of as "safe" code -- say the ability to do
arithmetic, create series, and so on.
But it does not contain native code to do anything "unsafe" -- like send or
read or write and much else.
Instead, those functions are passed back to the invoking program for checking
and actioning.
From the viewpoint of the calling program, it might look something like this:
untrusted-code: read %untrusted-code.r
do-unsafe/time-quota untrusted-code
[send: true ;; allows send without any checking
read: func [] [] ;; function to handle read on behalf of
untrusted code
]
0:0:02 ;; time quota 2 seconds
Any unsafe function not set to true or given a handler will not be permitted
do-unsafe loads the REBOL-macro interpreter, so the untrusted code has no
access to any mezzanines or the system object of the caller.
The untrusted code is halted (or there may be a call back for confirmation)
after 2 seconds elapse time.
***
REBOL as its own macro language is a flexible and powerful opportunity to do
some real X-internet applications.....It just needs to be made safe, as Gregg
says.
Sunanda.
[18/21] from: anton:wilddsl:au at: 5-Feb-2006 21:43
Actually, I was suggesting a simple firewall be added to
rebol's security. :-)
Anton.
[19/21] from: lmecir:mbox:vol:cz at: 6-Feb-2006 14:41
Hi Anton,
>How about a load/secure level ?
>where level none just does not allow the usage of /pro or /command
<<quoted lines omitted: 17>>
> level -- security level (Type: none block)
> >>
there is "only" one problem: Load cannot "arrange" this for you
-L
[20/21] from: sqlab:gmx at: 6-Feb-2006 18:19
Hi Ladislav,
Ladislav Mecir schrieb:
> Hi Anton,
>> How about a load/secure level ?
<<quoted lines omitted: 5>>
> there is "only" one problem: Load cannot "arrange" this for you
> -L
of course, it can not. But I wish, it could do it.
As it does now so different things as loading a library compared to
loading data and code including parsing, why should it not do that ?
[21/21] from: lmecir:mbox:vol:cz at: 7-Feb-2006 18:04
sqlab napsal(a):
>of course, it can not. But I wish, it could do it.
>
that is legitimate. I would like to have such a feature too, but I think
that I either don't understand you or that it cannot be done.
-L
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted