Noel, 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.
> Frankly, I don't want to run anything at root that can avoid > it. That is > just good practice. Sure, and you don't have to. Hey, we routinely run BEA WebLogic in distributed cluster of 20 big Sun/Solaris servers under ids. with just the required privileges rather than root and just the one JVM per machine, no problem. There are much larger similar configurations around. There is a big J2EE app. server base out there that has had to face these issues and resolve them. They have, so we can. > Consider Vincenzo's anti-spam matcher. Would you want that > to run as root? No, and there is no need to as explained above. Then I wouldn't want it to run with the same privileges as James or a James component either. It would be good to be able to define the launch environment for an executable, which is where most of the vulnerabilities occur. To be fair, I believe that Vincenzo has only looked at this from the Win32 perspective and doesn't have the options available on a Unix platform. > > There is no need to distribute James' components over > multiple JVMs to > > enhance security or robustness. > > I disagree as a technical matter. Such as? I can tell you in advance that my response will be that if a problem exists it should be fixed at source so that it works within a single JVM and then scales. Otherwise we are temporarily circumventing the problem and someday we will hit it again in a distributed solution and ultimately will have to fix it much more expensively. Been there. > I can give you plenty of good reasons for why you want the > ability to run > the mailet pipeline at privileges other than root: I think we are agreed that we don't want to run at root and hopefully I have shown that you don't need to. But the following is really useful in explaining why we don't want to and what we might want to distribute for performance reasons. > > - the chance of a JVM exploit. > - potential exploits via native code in > a JDBC driver. > - the use of native code in matchers/mailets, > e.g., the anti-virus matcher. > --------------------------------------------------- > - the use of third party matchers/mailets. > - the use of user-defined scripting matchers/mailets > - support for SOAP > - one pipeline being extra busy or big > performing lots of processing and/or > handling large messages, should not > deny service to other users. > I remain unconvinced that all of the issues are potential security risks, but as I tried to say in an earlier posting, its a matter of trust. We should certainly make James sufficiently configurable that it can be integrated into trusted practises wherever feasible, whether that trust is well placed or not. Conversely, James should be immune as possible from vulnerabilities exposed by malconfiguration. > Next, consider the dynamic reconfiguration issue, which > thread I have no had > time to respond to over the past couple of days.... Noel, I'll respond to this in the Dynamic Reconfiguration thread, but in short we're in agreement, you are echoing my thoughts here. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
