Well Andrew, "3" count them "3" security patches for VMS in five years ...
Bob Ceculski
decwindows ... the other two was for TCPware, one
being for smtp ... now where was slowaris cert count
for the last five years ... 1000+ and catching up
to linux windoze garbage ... beat that ...
Alan E. Feldman
> one was for something we don't even use right now ...
> decwindows ... the other two was for TCPware, one
> being for smtp ... now where was slowaris cert count
^^^^^^^^
> for the last five years ... 1000+ and catching up
> to linux windoze garbage ... beat that ...
WARNING!: This post is rated EUUL (Excessive Use of Uppercase
Letters): It contains an inordinate amount of uppercase letters.
Reader discretion is advised.
OK, Bob. You asked for it!!!
ATTENTION!!!: THE TIME 12:00 AM IS MIDNIGHT AND THE TIME 12:00 PM IS
NOON. IT IS THE DE FACTO STANDARD FOR AM/PM DIGITAL CLOCKS AND MANY
TRAIN AND BUS TIMETABLES.
AND I HAVE A VERY LARGE STORE OF SCARY, MEAN, MOFO UPPERCASE LETTERS!
AND I KNOW WHERE TO GET EVEN MORE OF THEM! HAH!
Disclaimer: HAH! &-)
Alan E. Feldman
Andrew Harrison SUNUK Consultancy
Trolling again Bob, I guess thats another new
years resolution that you should have made
down the drain.
Regards
Andrew Harrison
Mike R
> one was for something we don't even use right now ...
> decwindows ... the other two was for TCPware, one
> being for smtp ... now where was slowaris cert count
> for the last five years ... 1000+ and catching up
> to linux windoze garbage ... beat that ...
This comparison seems a little unfair, seeing as VMS security patches
aren't marked as security patches in the ECO notes or even the source
code as a matter of policy. I'm willing to bet the three you quote
were discovered by external people who refused to cover them up.
Anyone in the know care to estimate how many patches with a potential
security impact have been silently made in the last 5 years ? The
fact of the matter is that customers don't know how many security
patches there have been. As a side effect, this means that customers
can't choose to just apply critical security patches..
I think that "slowaris"'s rather more open and responsible approach
does indeed "beat that".
Larry Kilgallen
> Bob Ceculski wrote:
>> one was for something we don't even use right now ...
>> decwindows ... the other two was for TCPware, one
>> being for smtp ... now where was slowaris cert count
>> for the last five years ... 1000+ and catching up
>> to linux windoze garbage ... beat that ...
>
>
> This comparison seems a little unfair, seeing as VMS security patches
> aren't marked as security patches in the ECO notes or even the source
> code as a matter of policy.
I don't know ECO notes, but I have figured out the secret.
When something comes labeled "Mandatory Security Patch" it is for
security reasons.
The security fixes I know are not labeled as such are those which
are discovered internal to VMS Development where there is nothing
to indicate that any outsider has ever found the problem.
Andrew Harrison SUNUK Consultancy
Hence the bogosity of using CERT to compare OpenVMS security
with other OS's security.
Many of the CERT advisories for Linux and other OS's or common
OS components such as bind for example are published because
a security expert has trawled through the OS/components source
reviewed it and found a hole and published the details on the
hole often after suitable discussions with the effected vendors.
Many OS vendors also do the same thing.
OpenVMS is entirely different, the only CERT advisories reported
for OpenVMS are ones reported by 3rd parties the POP CERT for
OpenVMS for example and ones that Compaq/HP are/were forced
to post because there was a general vunerability to say POD
or LAND or Teardrop which they could not escape responding to
all be it regretably incorrectly in some cases.
You can count the number of CERT advisories posted by Compaq/HP on
their own volition on the fingers of one finger.
While OpenVMS sources are available they are not as easy to
get hold of as say the Linux source and anyway no one is that
interested in finding the holes so OpenVMS lacks the external
scrutiny accorded to other OS's. This coupled with a security
patch policy which doesn't specify what the patch is actually
for its just mandatory and you have a situation where CERT
counts for OpenVMS are a completely bogus measure.
Does this mean that OpenVMS is more or less secure than other
OS's, who can say certainly not someone using CERT as a
yardstick.
regards
Andrew Harrison
Larry Kilgallen
> Many of the CERT advisories for Linux and other OS's or common
> OS components such as bind for example are published because
> a security expert has trawled through the OS/components source
> reviewed it and found a hole and published the details on the
> hole often after suitable discussions with the effected vendors.
> While OpenVMS sources are available they are not as easy to
> get hold of as say the Linux source and anyway no one is that
> interested in finding the holes so OpenVMS lacks the external
> scrutiny accorded to other OS's.
A goodly portion of VMS security defects that made it to customers
have been reported due to customer inspection of the source. One
large set of those were released in a single security MUP before
Andrew started posting to those newsgroup.
While those involved "suitable discussions with the" a"ffected
vendor", the reporter obviously felt that the problem was well
in hand and felt no need to "go public" to get resolution.
VMS customers seem quite content with the security of VMS systems.
The person most disgusted with VMS security seems to be the person
trying to push a Unix approach :-)
Paul Sture
>
>
> Hence the bogosity of using CERT to compare OpenVMS security
> with other OS's security.
>
Andrew, for security reasons I cannot tell you what I know
:-)
--
Paul Sture
Bill Gunshannon
I could tell you what I know, but then I would have to kill you. :-)
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Mike R
exactly - internally discovered security problems are not labelled as
such. Sun alerts customers to all security issues regardless of who
discovered them. Therefore its a little unfair to play a numbers game
when one side isnt publishing the numbers...
Andrew Harrison SUNUK Consultancy
I am not disgusted with OpenVMS security and never have been.
I make no claims for Unix security except to observe the obvious
which is that the Unix approach of publishing vunerabilites at
least has that advantage of being more honest than the OpenVMS
policy.
My disgust is reserved for the people who argue that OpenVMS
has to be more secure than any other OS because it has less
CERT advisories posted for it than other OS's.
Disgust because it is dishonest. It also doesn't help OpenVMS
much because it makes people who may have valid points to
make about OpenVMS security look like the BS merchants who
tout the CERT numbers about.
Regards
Andrew Harrison
Bob Ceculski
> In article <btc7f5$b6t$1...@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No....@nospamn.sun.com> writes:
listen Andrew, VMS security mup kits are rarely issued, and
don't confuse ucx flaws with VMS os and kernel flaws ...
no one is hiding anything, except you, and you know the
truth is VMS has had 13 cert advisories compared to 1000's
for unix/linux/windoze convuluted garbage ... that's the
fact ... so quit trolling and put away your water gun
cause the black helicopters aren't coming ...
Andrew Harrison SUNUK Consultancy
Bob security holes in ucx are just as problematical as
VMS OS holes, don't get confused by that.
Claiming that the IP stack isn't really part of VMS while
counting IP stack advisories for other OS's in your BS stats
only serves to illustrate that you are just BSing.
Adding the CERTS for all the other OS's, UNIX, Windows etc
and comparing them with one OS VMS again only serves to show
that you are just BSsing. In case you hadn't noticed single
systems generally run one OS and are therefore only vunerable
to the exploits for that OS.
Claiming that TCPWARE etc are any better as you almost certainly
will is also BS, you misslead the group about TCPWARES vunerability
to a number of exploits an the patch reports caught you out (again).
A troll Bob is someone who keeps making BS claims that he/she
cannot justify in an attempt to generate discussion.
You have consistently shown yourself to be incapable of supporting
your claims instead as with most trolls you layer wilder and wilder
claims on top of allready disproven arguments.
Give up you are only making yourself and OpenVMS look silly.
Regards
Andrew Harrison
Mike R
> Kilg...@SpamCop.net (Larry Kilgallen) wrote in message news:<pHDs4F8$Eu...@eisner.encompasserve.org>...
> > In article <btc7f5$b6t$1...@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No....@nospamn.sun.com> writes:
>
> 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 ? :)
Larry Kilgallen
It depends on whether the stuff crossed-off get installed separately.
I run 6 VMS systems and none of them have TCP/IP.
Bob Ceculski
even with TCPware, only one security patch was issued mandatory
in the last few years that I have installed ... another was
for smtp ... so even with TCPware, you lose ...
Andrew Harrison SUNUK Consultancy
Bob how challenged do you want to appear ?
I don't lose because the measure you are using is
worthless. Its rather like the manager of a football
team claiming that the team he manages won despite
conceding more goals than the opposition because
he had more players in his squad.
Ask yourself another question, why is it just
you who is promoting this ridiculous test ?
There are plenty of people posting on this group
who have no hesitation in sliming another OS even
if they are only motivated by a desire to divert
attention from OpenVMS.
Could it be that all your potential supporters
are sitting on their hands because plucky little
Bob is doing fine by himself ?
Well you know the answer to that, Plucky little
Bob in fact could really do with some help.
Could the fact that your argument is basically
BS and worse BS that many OpenVMS advocates
would very much perfer not to have publically
examined because it poses more tricky questions
than they would like ?
Remember every time you have trotted out this
particular BS a small amount of research has
revealed more examples of why your argument
doesn't hold water.
I only found the TCPWARE vunerability documents
because you tried to slime UNIX again and I
really wasn't trying. How many vunerabilites
are there really out there, who knows but
every time you slime you get another vunerability
back in your face.
I generally don't have such a long term dialogue
with Trolls like yourself but you are proving to
be an incredibly usefully catalyst in helping to
burst the OpenVMS is as secure as a secure thing
mindset that most OpenVMS advocates appear to be
suffering from.
Regards
Andrew Harrison
Rudolf Wingert
the OpenVMS OS and its kernel routines do have less security wholes. But if you
will count some layered product as OS, then you are a little bit right. There
are a few security wholes within the TCP/IP ware. Because the new one comes from
the buggy UNIX. The must one security wholes are from the buffer overflow
problem. There are a lot of kernel routines and system integrated product within
UNIX (Solaris and LINUX included), which do have this problem. I don´t know no
routine within the OpenVMS kernel with that problem. Also will be a buffer
overflow within TCP/IP ware not a big problem (in case of memory protection),
because the normal user don´t get system priviledges.
Best regards R. Wingert
Keith Cayemberg
> > 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.
Keith Cayemberg
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.
keith.c...@conti.de (Keith Cayemberg) wrote in message news:<3a65a5c8.04010...@posting.google.com>...
And, then...
mechanism to be carried out by one program/process first
created at user request and has complete responsibility
for the entire login sequence.
Roy Omond
> [... snip ...]
>
> By the way, that was not by any means a complete list of OpenVMS
> design advantages. It was only a beginning.
[... snip ...]
> Cheers!
>
> Keith Cayemberg
> IBM Business Services - Hannover, Germany
^^^^^^^^^^^^^^^^^^^^^ :-)
Beautifully written, and spot on. Hear, hear !
Roy Omond
Blue Bubble Ltd.
Bob Ceculski
well Andrew, let see you respond to this ...
Keith Cayemberg
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.
Keith Cayemberg
IBM Business Services GmbH - Hannover, Germany
David Awerbuch
for being forthright and unambiguous, even as he is gamefully employed
by a competitor vendor.
Anyway ...
I will not get into particulars about how many CERT alerts per
system/vendor per year, or whether these alerts target the base OS vs
add-on packages. When we step back and take a look at the BIG
picture, we find a simple fact exists.
In the Systems Programming world that existed prior to the
popularization of the internet, intranets, and free Linux, when the
vendors were DEC, IBM, HP, DataPoint, Data General, Nixdorf,
Burroughs, NEC, and a bunch of others, before consolidation, before
Micro$oft and Linux, VMS was always recognized as the most secure and
most robust operating system in the world.
There is no better proof of this statement than that most of the major
banks, brokerages, and insurance firms (to name a few industries) in
the world (not just NY or the US) - implemented their most critical
business functions first on PDP-11s running RSX-11 and migrated to VMS
on VAXen and then later to Alphas, many of which are still running
today, all running under OpenVMS: Funds Transfer, DDA processing;
Securities Transfer, Trading Floor, back office; claims processing,
claims payment; this is only a partial list. Even the early ATM
support networks were developed for VMS!
Those of you like me, who have been in this industry for 25 years or
more, have time after time run into these work-horse systems,
stubbornly refusing to go away, because they will be very expensive to
reproduce. A good part of that expense is the need to ensure these
newly rewritten application systems remain as secure and robust as the
current production versions. This is a goal that, while achievable,
has not been as easy to attain on a single platform as it has always
been, and remains to be, with VMS.
Happy Computing!
Dave Awerbuch
Independent Consultant
APC Consulting Services, Inc.
New York, USA
P.S. For those who don't know me, I am not a VAX specialist. I have
worked on:
- DEC pdp-5, pdp-8 (OS/8e), pdp-11 (RT-11, RSTS/E, RSX-11m, Unix), Vax
(VMS/OpenVMS), Alpha (VMS/OpenVMS, WinNT)
- IBM System/3, System/34, Series/1 (RPS, EDX), System/88 (NSK),
System/360 (OS/MFT, OS/MVT, DOS, DOS/VSE), System/370 family (OS/VS1,
OS/VS2, OS/MVS, VM)
- HP 300, 2000, and 3000 family.
- Data General;
- National Semiconductor Datacheckers
- etc....
I'm not bragging or showing off, I'm just documenting that I have
worked on a lot of different multi-tasking systems, not just little PC
ones and not just VMS ones.
P.S.S. RSTS and RSX-11 are alive and well, being MAINTAINED and
SUPPORTED by Mentec. Inc. (http://www.mentec-inc.com/RSTSSW.html). I
would not be surprised to see a company like that take over VMS
support for the VAX when HP decides it will no longer support its
loyal DEC customers.
----- original message -----
X-News: eisner.encompasserve.org comp.os.vms:293007
From: keith.c...@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.04010...@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 ? :)
keith.c...@conti.de (Keith Cayemberg) wrote in message news:<3a65a5c8.04010...@posting.google.com>...
DL Phillips
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.
<top posted on purpose>
Keith Cayemberg wrote:
> > Mike R wrote:
> By the way, that was not by any means a complete list of OpenVMS
> design advantages. It was only a beginning.
>
<and a followup correction>