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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
