-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/09/2011 08:26 AM, Cullen Jennings wrote: > > I can't put my finger on why, but I get very nervous about suing downloadable > scripts to enforce critical system constraints such as security and quotas. > It just seems like a disaster waiting to happen. That said, I can't come up > with any specific problem of why it would not work but it makes me feel very > uneasy.
Here's what makes me nervous about this mechanism (and the ideas on this text will probably go into the security section in the next version of draft-petithuguenin-p2psip-access-control): Having a script in the configuration file is - in my opinion - not a security problem by itself. After all the configuration file is written by the same entity that will sign it and as long as the implementer follows the rules in the draft (no side effect when modifying the parameters, only base classes of ECMAScript implemented, etc...), this should not be a problem. It is even possible to deal with less than perfect implementations, as long as they do not accept a configuration file that is not signed correctly - for example the signer can have an active role, by deliberately sending in a ConfigUpdate an incorrectly signed version of the configuration file and blacklisting all the nodes that accepted it in a newly issued configuration file. One of the problems was presented at the mike in Prague by EKR[1]: Because now we have code inside the configuration file and because there is no way to find if this code will eventually stop executing in a reasonable time, we need to put a limit on the CPU used. Note that this is not so much for programming errors but because the set of possible inputs is very large there is no way to test them all. For example, an implementation written in java could be stuck in an infinite loop when using 2.2250738585072012e-308[2] in the Javascript code. Another problem that is not as easy to fix is that having a script in the configuration file introduces a single point of failure. One of the great thing about RELOAD is that it gives a way to design systems that can resist programmer's errors. Programmers make errors and - we had some examples of that recently - these errors can have huge impact. One way to mitigate that is to have multiple, separate, implementations of the same product, to have all of them running in parallel and use one of the implementations that behaves correctly. That is obviously extremely costly and is generally reserved to systems where life can be endangered by a software bug. What RELOAD brings to the table is a less expensive way to do the same thing. If an overlay is running on 4 or 5 different implementations, running on different OS and on different places, then the probability of losing it completely will be infinitesimal. If each implementation is coding the access control policy, then we still limit a coding bug to this implementation, but when the code itself is in the configuration, then an coding bug will impact all the implementations. And that is what make me nervous about this. [1] http://www.ietf.org/proceedings/80/minutes/p2psip.txt [2] http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3w+XoACgkQ9RoMZyVa61fNfQCeNWVTydHY4c/9v2wJEAABoi3S rm0AnRshgVFaXz0W/halRU+OXQzg7uPw =d/XW -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
