Achieving sysadm trust is not the same as achieving a maximally hardened solution. Perhaps James could achieve a level of trust from some Unix sysadms by making it possible to mirror the deployment environments that they trust. Fine. But as developers we shouldn't be blind to the fact this is a minor detour on the road to a maximally hardened solution.
I think a good equilibrium point between the "marketing" view of security (making sysadms trust) and purist java technical view would be to allow James not having to run as root under Unix (to handle protected ports like 25, 110, etc.) and then securing the rest of the processing through java security declarations.
I think having to run a big program as root looks always dangerous, as it makes far more difficult to know what it is doing or to scan it for security problems. Specially if it is extensible or takes third party extension modules (mailets, etc.)
This (and better) hardening could be achieved at the "pure" java level by granting specific permissions to different codebases/jars, using doPrivileged() when needed and running under a security manager, but I doubt most sysadms would be convinced if they don't understand java security. I, for one, could "buy" a pure java securiy solution, but I'm not a typical sysadm.
Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
