From: DL Phillips [whohe@whoever.com] Sent: Friday, January 30, 2004 12:49 PM To: Info-VAX@Mvb.Saic.Com Subject: Re: Well Andrew, "3" count them "3" security patches for VMS in five I can only presume that the reason neither Mike R. nor Andrew Harrison has responded is that each is carefully crafting a reply that will be as thoughtful as Mr. Cayemburg's. I hope they don't think we haven't noticed their non-response. Keith Cayemberg wrote: > > Mike R wrote: > > > Bob Ceculski wrote: > > > > > > > > listen Andrew, VMS security mup kits are rarely issued, and > > > > don't confuse ucx flaws with VMS os and kernel flaws ... > > > > > > Aah, that old chestnut. Whenever you discuss security with VMS guys > > > they always trot it out. Does that mean we can take your figure of > > > 1000+ solaris holes and cross off anything not in the kernel ? :) > > > > Yes, but first redesign and rewrite your unix to cleanly catagorize > and separate Kernel Mode from Supervisor Mode and from User Mode. > Three modes are a minimum for a correct ring protection system. The > use of three or more rings happens to be a fully patented methodology > by OpenVMS Engineering. OpenVMS has four. OpenVMS also has 40 groups > of higher mode functionality classified as requiring special named > privileges. > > And, then... > > - allow access to higher mode services only through a > DESCRIPTOR-based calling standard which rules out > "by design" the primary cause of security holes - > buffer-overflows. The secure Calling Standard is a > central design theme in OpenVMS. > > - rewrite and install your TCP/IP stack so that it > doesn't live in or directly access kernel mode > services except through the calling standard. If > the previous condition was met, your tcp/ip stack > probably won't work in Supervisor mode or User Mode > without these changes. This is the reason why most > security holes for which OpenVMS is affected does not > in fact lead to a security vulnerability. In this > sense I agree with Andrew. Security vulnerability > listings are innaccurate for OpenVMS. Because they > do not correctly differentiate whether only a user-mode > process can be affected or a higher mode, and whether > a higher privilege can be attained. A correct listing > must rate the severity of the security hole. In OpenVMS > the severity is usually lower (or meaningless) in > comparison to other operating systems. > > - design privilege assignments to be attached to a mode. > If a program installed in a higher mode breaks out to > a user-mode prompt. All privileges assigned during the > program run must be automatically lost. This prevents > program privilege tailgating. OpenVMS Hackers (yes they > do exist, an admirably persistent if unsuccessful lot) > have recently discovered this functionality in OpenVMS, > inwhich they intentionally installed an application > with privileges and with a buffer overflow leading > to a DCL prompt. Their experiment failed. This OpenVMS > "knockdown" functionality can also be extended to > disable the privilege of receiving a DCL Prompt when > breaking out of a program or DCL procedure, just by > assigning the CAPTIVE and RESTRICT flags to user accounts. > > - design your Unix to provide only strictly separated > (and from overflow controlled) user and system stacks > to prevent stack crashing leading to access to higher > mode functions. > > - lets also not forget a redesign of the internal logon > mechanism to be carried out by one program/process first > created at user request and has complete responsibility > for the entire login sequence. > > By the way, that was not by any means a complete list of OpenVMS > design advantages. It was only a beginning. > > These are only a few of the unique, patented design decisions in > OpenVMS resulting in a world-beating matrix of Functionality, > Reliability, Availability, Security, Stability, and Scalability(RT, > APMP, SMP and Cluster). It's an OS that was "Designed" first by 4 > competing teams of experts, and then the best results of these > competing design teams merged into a final design team. They knew of > the older Unix, MVS and Multics designs, and naturally they innovated > and improved on them for the Enterprise OS problem space. > > When you are done making these elementary design changes to Unix (many > of which were intentionally excluded or ignored by the Unix designers > in 1969 - Multics already had early forms many of them) you will find > most of the commercial products on the Unix Market will no longer > function correctly on your New-Unix, and will also require a redesign, > and then a rewrite. > > But at least you will finally have an OS and TCP/IP stack which > "begins" to technically compare with OpenVMS within the frame of > security. And you'll have a product which pays royalties to OpenVMS > Engineering. > > Each OS has it's strengths and weaknesses in design and implementation > which will have a different evaluation depending on the problem space > it will be applied to, and depending on the design goals of the > designers. For the general Enterprise OS problem space, I believe > OpenVMS Engineering has most consistently made the best decisions in > design and implemented them with an admirably consistent high quality > and methodology. > > OpenVMS enthusiasts can righteously bemoan that the Computer Science > Profession (Informatics) have failed to recognize and teach their > students the sophisticated mechanisms and high principals found in > OpenVMS, preferring instead to favoritize the minimalistic asthetics > of Unix, or the marketing level sophistication in OS selection. This > is a real loss for enterpise efficiency (money), mission-critical > system stability (lives), and the computer science profession > (maturity as a science). A more balanced and impartial framework of > scientific thought is needed. Computer Science needs some independence > from commercial and marketing interests to even discover the value of > many existing designs, technologies > and ideas. The last major papers over OS design were written over 10 > years ago, but their work is far from complete. > > Critics of OpenVMS should first study and compare it's internals > (Professional OS comparisons and choices should not be reduced to an > application layer beauty contest) with an open mind concering OS > design paradigms, system operations principals and reliability > methodologies. After recovering from the shock, they will likely no > longer be as critical. > > Cheers! > > Keith Cayemberg > IBM Business Services - Hannover, Germany > > Semi-Nonstandard Disclaimer: > Any non-official claims concerning my semi-official > opinions are hereby officially disclaimed. > i.e. I said it, not my employer. > (and no I didn't steal this one from Yogi Berra) > > I welcome rebuttal, however a lack of response on my part only > indicates a lack discretionary time to indulge in discussions > peripheral to my employment activities. >Excuse me one last time, I have checked my sources and find I need to >change one sentence of my earlier Email. The sentence should read... > > It's an OS that was "Designed" by experts first producing > four design iterations, and then the best results of these > designs were carried over into a final design by "The Blue > Ribbon Committee". >