that wants ...
On Mon, Nov 5, 2012 at 2:35 PM, Andrea Giammarchi < [email protected]> wrote: > 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 <[email protected]> wrote: > >> >> >> >> On Mon, Nov 5, 2012 at 2:22 PM, Andrea Giammarchi < >> [email protected]> 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 <[email protected]>wrote: >>> >>>> >>>> On Mon, Nov 5, 2012 at 1:11 PM, Andrea Giammarchi < >>>> [email protected]> 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 <[email protected]>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 >>>>>> [email protected] >>>>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> --MarkM >>>> >>> >>> >> >> >> -- >> Cheers, >> --MarkM >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
