www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <dun...@x180.net>
Subject Re: WORA Considered Evil ;-)
Date Wed, 02 Jul 2003 15:28:56 GMT
Some random thoughts--aside from the personal defense against a 
perceived attack which I'm not wanting to get involved with. :)

On Wednesday, July 2, 2003, at 12:53 AM, Steve Brewin wrote:

> I did say "I'm sure that everyone is in favour of hardening James as 
> much as
> possible. Its just that we should approach it from a Java perspective, 
> not a
> C on Unix one. The issues are different."

The only real issue that is different is that you don't have to worry 
about memory overflows since the VM doesn't allow it. Other than that, 
all of the basic security worries are the same no matter what language 
the system is written in. And since quite a few security holes are 
exploits of the code paths of a program rather than buffer overflows... 
it follows that the issues aren't necessarily different.

> Why? Because the potential vulnerabilities and the optimum measures to
> eliminate them are not the same for the two environments. To take an
> approach that assumes that they are the same will result in a less 
> hardend
> solution. Examining the risks as they exist in James' Java environment
> deployed on physical OSes such as Unix will achieve a maximally 
> hardened
> solution.

The problem is that you can't really examine the risks all the way. A 
large part of being a security weenie is protecting against what you 
can't predict. And that's where the Unix BOFH mentality on security 
comes from--decades of seeing what works and what doesn't. Trying to 
say that the problem doesn't exist or is different using Java isn't 
really helpful.

> Achieving sysadm trust is not the same as achieving a maximally 
> hardened
> solution.

The latter is something that you can't prove, you can only show good 
results with time. The former at least means that you play by rules 
that are known to work well.

To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

View raw message