OpenVMS vs unix security ... Andrew, the IBM guy awaits your response!

From: Bob Ceculski (bob_at_instantwhip.com)
Date: 01/31/04 

Date: 30 Jan 2004 16:50:20 -0800

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

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.

Excuse me. I just noticed I didn't finish writing the last condition.
It should read...

 - 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.

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".

I had thought to have read that the original 4 designs were by four
competing teams, but I can no longer find a source for this. The
essential message remains unchanged. OpenVMS was carefully "Designed"
by experienced operating system experts.

I'm not interested in changing history for any purpose. I do stand by
my other statements and opinions made in the email.

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.

Quantcast