avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Coding Standards Update
Date Sun, 24 Jun 2001 15:30:41 GMT

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: den 21 juni 2001 15:23
> To: avalon-dev@jakarta.apache.org
> 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?


To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message