Re: libseed-list Seed constrained context

["Alan Knowles" <alan akbkhome com>]

looking at this it might make sense to make the engine api a bit more 'gobject like'
eg.

SeedEngine* seed_engine_new(argv, argc)
void        seed_engine_set_context(SeedEngine*,...)
void        seed_engine_set_group(SeedEngine*,...)
void        seed_engine_import_enable(SeedEngine*,true|false)

void        seed_engine_init(SeedEngine*)

we could then depreciate the seed_init_with_* methods.  

Does that help you multiple instance concept?

Regards
Alan

 --- On 28/Mar/2011, Alexandre Mazari wrote: 
> Hi Alan,
> 
> The main point of this patch is to reduce the surface of potential
> attack from within the JS context when executing arbitrary code (comming
> from the web, or a PDF file for example).
> 
> That's why I decided to hide the importer altogether. I am not certain
> it has receive enough testing to be qualified as bulletproof.
> 
> Also the 'imports' keyword is quite common in web libraries, causing
> eventual names clash.
> 
> Depending on the use-case, the freedom granted to the JS context might
> vary, and allowing/forbidding the importation of whitelisted/blacklisted
> namespaces are definitely a tool in this palette.
> 
> With the following security levels, I think we cover most of application
> writers requirements:
> - full context: can import any ns/module/script
> - restricted/constrained context: nearly what you propose, allow
> importation of everything but blacklisted ns/modules/scripts.
> - empty context: what's proposed in this patch: completely disallow
> importation, pushing *chosen* ns from C.
> 
> Of course application devs input would be appreciated.
> 
> What do you think ?
> 
> 
> Le lundi 28 mars 2011 à 09:42 +0800, Alan Knowles a écrit :
> > Looking at the code, I did wonder why you did not use whitelisting with the importer
> > eg.
> > 
> > seed_importer_add_whitelist("Gtk");
> > 
> > then just modify the importer to check if a whitelist exists and  return an empty object if it the requested import is not in the whitelist..
> > 
> > Regards
> > Alan
> > 
> > 
> >  --- On 25/Mar/2011, Alexandre Mazari wrote: 
> > > Hi Tim !
> > > 
> > > > Bugzilla is down, so I'm sending you an email instead
> > > 
> > > Yeah makes life harder. Need our daily bugs fix.
> > > > 
> > > > isn't this functionality more or less what Seed's built-in Sandbox
> > > > module does?
> > > 
> > > >From what I understand, and please correct me if I am wrong, both are
> > > related to security and isolation but they are orthogonal IMHO.
> > > 
> > > The proposed patch allow the creation of an empty engine/context where
> > > the developer from C. This context disallow the js code of importing
> > > arbitrary namespace, object, script or module. 
> > > The context is *selectively* filled by the C developer of *choosen*
> > > namespaces and objects.
> > > The main use-case is an application executing arbitrary JS code (coming
> > > from the web for example). Obviously, you dont want this code to import
> > > Gio and play with your filesystem.
> > > 
> > > On the other hand, the Sandbox module's provides a mean to create
> > > isolated context from within JS.
> > > >From what I gather from the source, the sandboxed context is filled with
> > > the builtins and the import system.
> > > Also the module API is not public (in C).
> > > 
> > > I do think both solutions answer to different problems, and each has its
> > > place in Seed.
> > > 
> > > Thanks,
> > > 
> > > Alexandre
> > > 
> > > 
> > > _______________________________________________
> > > libseed-list mailing list
> > > libseed-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/libseed-list
> > 
> > _______________________________________________
> > libseed-list mailing list
> > libseed-list gnome org
> > http://mail.gnome.org/mailman/listinfo/libseed-list