On Monday, 03/26/2007 at 10:53 AST, David Boyes <[EMAIL PROTECTED]> wrote: > As far as I know, no one has conducted a formal evaluation of the SSL > Enabler appliance system yet, and I don't remember any explicit > commentary in the IBM security reviews on SSLSERV (but my memory is not > what it used to be, I'm afraid).
IBM makes no claims about what the SNA SSL Enabler appliance does or does not do. > There is commentary in the IBM TCPIP documentation (in the planning and > administration guide) on SSLSERV and how it operates, and the > installation README file inside the RPM describes at what point the IP > stack in the Linux guest is rendered non-functional. After that point, > it's pretty tough to change *anything* in that guest without access to > the virtual machine console (which would be covered by your VM security > package) and even then, you'd have to be comfortable with line-mode > editing tools at an unusually capable level. The number of people with > Unix experience on real TTYs is not growing...8-) When installed in the IBM-supported environments according IBM documentation, four layers of protection are provided: 1. The SSL server's native AF_INET IP stack and device drivers are rendered inoperative. 2. The only service that is running is the SSL administrative interface. 3. The SSL admin interface binds to the loopback address to limit connections to local VM TCP/IP apps. 4. It uses assists in the VM TCP/IP stack to ensure that only users in the VM TCP/IP obey list can connect to the administrative interface. With all four layers of protection in place, I feel that the SSL server is [more than?] reasonably protected from unauthorized tampering. Naturally, if you give someone access to the SSLSERVE virtual machine itself, none of those protections amount to a hill of beans. But, using one of my freshly-printed Get Out of Jail Free cards, I declare that as "Authorized Tampering". Alan Altmark z/VM Development IBM Endicott
