Even for regular languages the basic decision problems have exponential complexity. That's certainly better than undecidable, but it shows that even for such a rudimentary computational model basic security questions are costly to answer.
In light of this the sandbox approach is a bit of a false sense of security. It allows you to answer a very restricted set of decision problems about submitted scripts, but not all the questions you might eventually need to answer. On Apr 27, 2014 11:44 PM, "O'Shannessy, Liam" <liamos...@gmail.com> wrote: > > Interesting question. > > Disallowing any Turing complete languages from an operating system would > make for a pretty boring operating system, as it would effectively be > impossible to program for. > > My take on it is that it is that langsec is saying that "with great power > comes great responsibility". If a developer is given the privilege to > create an application in a Turing complete language, langec should be used > to guide security considerations for that application. > > In the case of web applications, it's clear that if we want web > application developers to actually be able to write web applications > meaningful client side execution, we need to be very careful, as we're in > the Danger Zone - the "parser" (browser or other js execution environment) > is accepting "messages" (the js components of a web page) which are of a > dangerous grammar complexity (at least context-sensitive iirc). This > accepting of dangerous messages is compensated for by controls in > javascript execution environments (Safari/iOS) like javascript sandboxing, > and strictly limiting what cross-domain access a script has. > > Liam > > > > > > On Sat, Apr 19, 2014 at 4:04 PM, David Aiken <david_ai...@yahoo.com>wrote: > >> hi all.. >> >> Javascript is Turing complete, as is HTML+CSS. IOS is very restrictive >> yet supports these languages.. but it still seems to be too permissive >> according to http://langsec.org/occupy/ . Your recommendation, as i >> understand it, is to simplify input languages such that they can be >> expressed as a regular language or deterministic context-free grammar. Is >> my understanding correct? If so, are there any proposals wrt replacing the >> functionality of these languages in a manner consistent with your >> recommendation? >> >> thanks, >> David >> _______________________________________________ >> langsec-discuss mailing list >> langsec-discuss@mail.langsec.org >> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss >> > > > _______________________________________________ > langsec-discuss mailing list > langsec-discuss@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss > >
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
