my point on namespaces was this one: everyone want's to use jQuery, then underscore, then this or that ... then you need to be able to modify the white list.
On Mon, Nov 5, 2012 at 2:28 PM, Mark S. Miller <erig...@google.com> wrote: > > > > On Mon, Nov 5, 2012 at 2:22 PM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> not sure I follow the single thread part which I believe isn't bringing >> anything new here or maybe I have missed the point. > > > My point was only that, in SES, the attack you showed is only an attack on > availability, and so a non-issue. > > > >> >> What I am saying is that only via that SES "thing", or similar parsers, >> > > SES gets its security without needing to do a full parse. That's part of > why it's cheap and reliable. > > > > >> you might add security but I wonder if the Function, as far as I can tell >> being allowed, is able to create runtime potential problems after SES >> resulting in opened doors for attacks. >> > > SES replaces the Function constructor with a safe alternative > > http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#733 > > > > >> >> Anyway, if performance is not an issue then yes, such parser with >> whitelist is the least someone should think about but I don't see that >> natively implemented, >> > > SES doesn't need to do a full parse. > > > >> also because everyone would like to be able to add own namespace in the >> list and I believe making a white list modifiable from anyone is again a >> security problem. >> > > Making the whitelist modifiable would be fatal. I don't understand your > point. > > > >> >> >> On Mon, Nov 5, 2012 at 2:12 PM, Mark S. Miller <erig...@google.com>wrote: >> >>> >>> On Mon, Nov 5, 2012 at 1:11 PM, Andrea Giammarchi < >>> andrea.giammar...@gmail.com> wrote: >>> >>>> I see security problems all over ... you own your function, you can >>>> make it "pure" or serializable ... you don't know your function, I believe >>>> there's no way you want that unknown function to be executed in your own >>>> sandbox opening doors for any sort of attack, i.e. ... this is pure, no >>>> outer scope access at all: function pure() { function(){return >>>> this}.call(null).Function.prototype.serialize = function() { /* boom */ } } >>> >>> >>> JavaScript is singly threaded. Within a given JavaScript >>> thread/process/worker/vat/whatever, any code which is ever given control >>> can just go into an infinite loop or throw, so none of the within-vat >>> sandboxes attempt to make any claims about availability[1]. However, SES, >>> by following the object-capability model, makes strong claims about >>> integrity. Irakli's notion of closed strict functions is adequate for safe >>> remote execution, where "safe" means that it can cause no effects on the >>> integrity of its importing context not explicitly authorized by the >>> references passed into it. >>> >>> >>> [1] MS WebSandbox claimed only resistance to availability accident, not >>> to availability attack. >>> >>> >>> >>> >>>> >>>> >>>> On Mon, Nov 5, 2012 at 12:19 PM, Herby Vojčík <he...@mailbox.sk> wrote: >>>> >>>>> >>>>> >>>>> Irakli Gozalishvili wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I keep running into cases where I would like to know if function is >>>>>> pure. Although my interpretation of pure is not quite right but I >>>>>> don't >>>>>> know any better name. By pure in this context I would refer to >>>>>> functions >>>>>> that don't access an out scope variables and don't >>>>>> do any mutations of itself or it's properties no references to itself >>>>>> could be an option too. My intended use case for such a feature is to >>>>>> >>>>> >>>>> IOW, 'stateless'; or 'serializable'. For in fact it means, that I can >>>>> send f.toString() to the other side and when evaled, I can use it. >>>>> >>>>> >>>>> processes too, it would be great if we had something like >>>>>> Function.isPure(f). Also as far as I know jits already capture this >>>>>> info >>>>>> for optimisation purposes maybe it could be exposed ? Another >>>>>> alternative could be pure(function() { …. }) that would throw compile >>>>>> error if >>>>>> function followed is not pure. >>>>>> >>>>> >>>>> Yes, it could be nice to have some API to help with this. Maybe not >>>>> generic isPure or the like, maybe Function.serialize(f) and >>>>> Function.deserialize(**serialized_f) would be enough, the former >>>>> returning null if not pure/stateless/serializable. >>>>> >>>>> It is good to note that the function is serializable not only if it >>>>> has no outer pointers, but also when its outer pointers only point to >>>>> 'known primitives' (numbers, strings, null, true, false; not symbols). >>>>> >>>>> >>>>> >>>>>> Thanks! >>>>>> -- >>>>>> Irakli Gozalishvili >>>>>> Web: http://www.jeditoolkit.com/ >>>>>> >>>>> >>>>> Herby >>>>> ______________________________**_________________ >>>>> es-discuss mailing list >>>>> es-discuss@mozilla.org >>>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss@mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>> >>> >>> -- >>> Cheers, >>> --MarkM >>> >> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
