[Vms.sig-hu] VMS Pearl from comp.os.vms and a customer (fwd)

Fodor Zsuzsa fodor31 at freemail.hu
2004. Jan. 14., Sze, 23:38:43 CET


---------- Továbbított levél ----------
Dátum: Mon, 12 Jan 2004 10:41:16 -0500
Feladó: Skonetski, Susan <susan.skonetski at hp.com>
Címzett: Skonetski, Susan <susan.skonetski at hp.com>
Tárgy: VMS Pearl from comp.os.vms and a customer

Normally I would not forward the entire string but the very end of this
is worth it.  Please do read in order.  This is in a public forum

Players

Larry Killgallen - OpenVMS Security Expert - External
Andrew - Employee from one of our competitors
Keith - well you need to read in order to see where Keith comes from.

Warm Regards,
Sue


-----Original Message-----
From: Larry Kilgallen (text only, no HTML or MIME)
[mailto:qaxhy6v02 at sneakemail.com] 
Sent: Friday, January 09, 2004 7:15 PM
To: Skonetski, Susan
Subject: VMS Pearl from comp.os.vms


Sue-

Be sure to read the following in order -- no skipping ahead to the end
:-)

X-News: eisner.encompasserve.org comp.os.vms:293007
From: keith.cayemberg at conti.de (Keith Cayemberg)
Subject: Re: Well Andrew, "3" count them "3" security patches for VMS 
in
five
Date: 9 Jan 2004 11:02:00 -0800
Message-ID: <3a65a5c8.0401091049.199aa813 at posting.google.com>

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

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.










További információk a(z) VMS.SIG-hu levelezőlistáról