> -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED] > Sent: den 21 juni 2001 15:23 > To: [email protected] > Subject: Coding Standards Update > > > I beleive we need to go through our Coding Standards document, > purge some items (since they do not apply to modern JVMs) and > incorporate ideas from this list of documents: > > Twelve rules for developing more secure Java code > ------------------------------------------------- > http://www.javaworld.com/javaworld/jw-12-1998/jw-12-securityrules_p.html
While I belive that the rules are appropriate for some situations, I do not think that they approach the type of security needed in Avalon from the right angle. Besides leading to a lot less developer-friendly code I think they ignore one important point: If someone else chooses what code gets executed on your machine, you can not claim any security. Almost all "gotchas" that were listed assumed that the attack came on the form of malicious classes that forced a violation of the contract between the objects in the system. Now, given the existence of Java decompilers and the fact that Avalon is open source and thus available for any attacker to modify, I must question an approach to security that puts this great an emphasis on the types of attacks described in the article. Instead, I believe that the fact that Avalon is open source, coupled with peer-review and the possibility of source code inspections are the things that make Avalon "secure". In the same way as one usually lets the OS handle file permissions, I believe that untrusted code must run in a sandbox, just like applications run in user space and not kernel space, and that security is therefore best handled at the VM level. I get the feeling that we're trying to patch small security holes while there's a train-sized hole that we can never cover up and that all attackers will use. I assume that there are people on this list with more experience in this field, so what do you say? /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
