Re: Happy 10 years of continuous virus free computing on OpenVMS alpha 7.1

On Jun 9, 10:52 pm, "Robert Jarratt" <nos...@xxxxxxx> wrote:
<ultra...@xxxxxxxxx> wrote in message

news:90d9d32c-ee99-435b-84d9-c46d9701268f@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

how many other OS's can claim that?

well we can can on OpenVMS 7.1

and we have another 4 years planned on it ...

I suspect this might cause some debate, but frankly I don't think this
proves anything other than that malware authors do not see VMS as a
worthwhile target, because they would profit very little from attacking it.
Don't get me wrong, though, I love VMS.

Regards

Rob

Why does nobody here appear to know that the OS architecture of
OpenVMS provides an inherent security advantage over all the other
OS's mentioned here?

Yes, a perfect security coupled with a practical, usable OS is
probably an unreachable goal. But the integrated architectural
advantage of OpenVMS brings it much closer to such a goal than any OS
which just layers security features on top of it's architecture.

While it is possible to write a virus for OpenVMS, and maybe even
infect a user-mode process, perhaps through a buffer-overflow in a
poorly programmed third-party application also running in user-mode.
It is very much more more difficult on OpenVMS to actually to use a
buffer overflow or other exploit to gain any higher mode privilege to
actually control or degrade the security or stability of an OpenVMS
system which has been properly configured. The basic principles have
been mentioned by myself and others in this forum years ago. In fact
they were mostly well developed in the MULTICS OS in the 1960's, and
promptly ignored by the Unix fathers who had other goals than a secure
OS in mind. OpenVMS developed these principles a little further while
maintaining a practical and manageable balance of features.

- First, a secure OS architecture must have at a minimum 3 security
rings or modes. This is simple common sense, since it is necessary to
protect the kernel from the third-party apps and the third party apps
from the user. All Unix, Linux and Windows derivatives have only 2
security rings/modes. OpenVMS has 4 rings. The extra ring is used to
protect the (eventually changeable) CLI from the user, and the other
higher modes from the CLI.

- Second, all services and privileges which can be requested from a
higher mode must be performed through a standardized calling standard
that only permits calls where the parameters are "called by
descriptor". This virtually eliminates buffer overflows as a source of
attaining higher mode privileges or services for which a process was
not explicitly entitled. Buffer overflows are the source of the vast
majority of the security vulnerabilities announced for all the other
OS's the past 30 years. Building such protection into you OS provides
a significant advantage that is much less dependent on the honesty or
skill of third-party developers, and does not not depend on needing to
acquire, read, understand and debug their source code (which may or
may not be what your executable was really built from).

Unfortunately, you will generally not find the above principals in the
currently used University-level texts on OS Design. And, the
professors appear to be ignorant of, or be uninterested in these
principals, which disprove Microsoft's recurring mantra that all OS's
are relatively equally insecure. In the many OS design books I have
reviewed, I have never seen a mention of a descriptor-based calling
standard coupled with a minimum 3 protection mode design. These
principals however become apparent when understanding Ruth
Goldenberg's IDSM books and various MULTICS security articles.

Here I would like to mention, an accidental bug can potentially be
more clever at degrading security than the best hacker/cracker.
Consequently, good security design is actually synonymous to good
reliability design of a system. Both reliability and security are
compound LCD qualities, meaning it is only as strong as it's weakest
link, and due to it's complexity, and the difficulty to balance
usability and security, the OS is traditionally one of the most
neglected links of the IT security quality chain. Consequently,
security features are often only layered add-ons in most OS's allowing
widespread configurations which default to not having these add-on
security features. This leads to the large "ecosystem" of easily
exploitable OS instances which hackers are taking advantage of.

To say OpenVMS is secure "only because it is not as popular" as other
OS's is a patently and provably wrong statement. It is wrong when you
consider OpenVMS's security architecture compared to other OS's, and
it's wrong since OpenVMS has had it's "trial-by-fire". OpenVMS was
actually a primary target of professional hackers in the mid 1980's to
early 1990's. This has been documented in various books and articles.
This was due to the large body of corporate and institutional secrets
which were to be found on OpenVMS systems. For instance, NASA's SPAN
network was DECnet based and a repeated target of Russian espionage
such as witnessed in reports on "Hanover Hackers/Crackers", the
loginout code exploit of Kevin Mitnick or the spread of the "Wank
Worm". In all these cases it was necessary to have the password of a
username with higher mode privileges to enable the compromise of a
system. OpenVMS had it's "trial-by-fire" with regards to security long
ago. And in those cases, it was "people" who proved to be the weakest
link, not the OS. The same definitely can not be said of the
competition in the enterprise OS market.

The realization that the OS is the regulating central architecture to
providing for enabling a secure system and reliable is diametrically
opposed to today's mantra that the application alone should/is
important to the customer, and the OS should be irrelevant.

There are many other security principles which are realized in the
design and practices surrounding the OpenVMS, but to a much lesser
degree, if at all, in other Enterprise OS's.

- no application can be more capable or secure than it's OS design
permits. This is a result of the LCD compound quality of security
mentioned above. Security is a chain of links, each of which must be
strong on it's own. In the IT world, links of a chain are analogous to
the layers of technology implemented starting from the user, network
OSI layers, application layers down to the kernel, hardware and
physical location of the system. For example, if an application layer
is encrypting it messages to the equivalent application running in
another city. That application is still not more secure that the OS
underneath it, which when compromised, allows the viewing of the plain
text when the user is reading it himself.

- dependence on the review of Open-Source in terms of reaching a
secure OS is a red-herring. Especially since OS and application code
fluctuation and complexity virtually guarantees the perpetual
existence of security impacting SW bugs. The OS design must provide
mechanisms to explicitly avoid classes of exploits and coding bugs
through the design of it's OS architecture. The corollary to this is
that it is pure hubris to think anyone is so expert about the quality
of all third-party applications they are using that they can maintain
"a secure system" only because the purported source code is "open" and
available for public review.

- the segregation of all security/stability affecting activities into
multiple clearly defined privileges, which limits exposure of higher
modes to applications and users temporarily requiring a specific
privilege.

- protection of all individual OS structures, services, and objects
(processes, threads, monitors, etc.) with "individual security
profiles" which can be finely tuned to allow/refuse access to any
other individual or class of OS structure, service or object.

- the default installation of privileges and protections should start
with a new user always having minimal but usable access to OS
privileges and services.

- user access to higher privileges should only be through known and
validated applications installed with the needed privileges and coded
to carefully to only allow intended actions.

- A known/unknown bug in any privileged application that allows one to
break out to a command line should still never allow the user to
maintain an application-level privilege in that interactive mode. The
capability to recognize this should be an inherent capability of the
OS architectural design. OpenVMS does this, and on OpenVMS a system
administrator can even refuse any or all users the privilege to have a
command line. This totally eliminates a class of exploit.

If you pull all the information together you can find on these
concepts, and forget any bias you may have had indoctrinated in you
about what an OS kernel is and must provide as a service. Then you
should come to the inescapable conclusion that all Unix, Linux and
Windows variants (please see the "Shatter Exploit" for an example of a
failed OS API) are inherently non-secure by design, and to change that
would require breaking completely with upward compatibility and
leaving their valuable application ecosystem behind. Microsoft has
already struggled with the upward compatibility and acceptance of it's
VISTA OS while trying to implement only a very limited improvement of
a coordinated restriction software installation and user privileges
with it's UAC feature. Although perhaps a step in the right direction
in terms of security, the feature is almost universally disliked by
Windows user's and is often immediately turned off. Please see user
comments here...<http://www.theinquirer.net/gb/inquirer/news/
2008/04/22/windows-milestone-outed>


Cheers!

Keith Cayemberg

.

Relevant Pages

  • Re: Well Andrew, "3" count them "3" security patches for VMS in five
    ... Whenever you discuss security with VMS guys ... be a fully patented methodology by OpenVMS Engineering. ... calling standard which rules out "by design" the primary cause of ... - design privilege assignments to be attached to a mode. ...
    (comp.os.vms)
  • Re: Well Andrew, "3" count them "3" security patches for VMS in five
    ... business functions first on PDP-11s running RSX-11 and migrated to VMS ... "3" count them "3" security patches for VMS ... > be a fully patented methodology by OpenVMS Engineering. ... > These are only a few of the unique, patented design decisions in OpenVMS ...
    (comp.os.vms)
  • Re: Linux on its way out - unless you are a geek ...
    ... and here is how to put unix on the same level security wise as ... but first redesign and rewrite your unix to cleanly catagorize ... be a fully patented methodology by OpenVMS Engineering. ... calling standard which rules out "by design" the primary cause of ...
    (comp.os.vms)
  • Re: OpenVMS security?
    ... > security knowledge. ... be a fully patented methodology by OpenVMS Engineering. ... calling standard which rules out "by design" the primary cause of ... - design privilege assignments to be attached to a mode. ...
    (comp.os.vms)
  • Re: OpenVMS security?
    ... OpenVMS is mostly written in a variety of type-safe languages, ... He is a security expert - ... The VMS kernel is mostly a DEC language claled BLISS and VAX Assembler. ... Getting privileges you don't have is ...
    (comp.os.vms)