Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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:gmai:l 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:gm:ail 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:gm:ail 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