1 INFO-VAX	Sat, 17 Jul 2004	Volume 2004 : Issue 393       Contents:" Re: Audit Trail of Interactive DCL Re: DECnet question  Re: DECnet question D Re: Do customers need to support DECforms in DECwindows using Motif? Re: Is a file open Re: Is a file open7 Re: Is it possible to route or tunnel the SCS protocol?   Re: LOGIN.COM comparison utility OpenVMS security?  Re: OpenVMS security?  Re: OpenVMS security?  RE: OpenVMS security?  Re: OpenVMS security?  Re: OpenVMS security?  Re: OpenVMS security?  Re: OpenVMS security?  Re: OpenVMS security? 1 Re: Turn-key OpenVMS E-mail, web server solution?  What could of been ...  F ----------------------------------------------------------------------  % Date: Sat, 17 Jul 2004 08:35:14 +0000 - From: David B Sneddon <dbsneddon@bigpond.com> + Subject: Re: Audit Trail of Interactive DCL * Message-ID: <40F8E4C2.8030205@bigpond.com>  & David J Dachtera was overheard to say: > dooley wrote:  > I >>There was some freeware called PHOTO in the supervisor series software, H >>however it was VAX only - I don't know if an alpha port was ever done. >  >   > Can the VAX version be VESTed? >  > D.J.D.  E Because of it's dependency on internals I don't believe it will VEST. F But there is the LOGGER program on one of the recent Freeware CDs that' does a similar thing using FTA devices.    Regards, Dave.  --  I David B Sneddon (dbs)    VMS Systems Programmer     dbsneddon@bigpond.com I Sneddo's quick guide ...          http://www.users.bigpond.com/dbsneddon/ I DBS freeware at ...   http://www.users.bigpond.com/dbsneddon/software.htm I "Life is what happens to you while you're busy making other plans" Lennon    ------------------------------  # Date: Sat, 17 Jul 2004 07:08:17 GMT 0 From: glen herrmannsfeldt <gah@ugcs.caltech.edu> Subject: Re: DECnet question- Message-ID: <Bf4Kc.98619$%_6.64177@attbi_s01>    Jay Olson wrote:K > I have a question concerning DECnet task-to-task communications. We have  J > an application which uses DECnet task-to-task communication to start up K > and communicate with some other programs. These programs in turn talk to  G > other systems with TCP/IP. On some days, these programs get busy for  I > some reason (most likely TCP/IP network problems) and they may not get  8 > around to reading from the DECnet channel for a while.  F > It appears that the main program can do a $QIOW to send data to the G > TCP/IP communication programs and the write will complete before the  I > other end has read the data. In fact, the $QIOW will copmplete even if  J > the other end doesn't have a read active. However, this can only happen K > a limited number of times, after which the $QIOW does not complete until  $ > a read is issued on the other end.  B I believe this is a property of most TCP implementations.  Much ofC the speed advantage of TCP comes from this property.  It seems that > it is being passed through to your application, even if DECnet doesn't have that property.    -- glen    ------------------------------  # Date: Sat, 17 Jul 2004 16:50:27 GMT 7 From: Jay Olson <jay.olson@triton-software.com.no.spam>  Subject: Re: DECnet question: Message-ID: <40F95900.5040701@triton-software.com.no.spam>  H Perhaps you misunderstood my qustion. I am asking about what parameters F control when a $QIOW write to a DECnet channel will succeed/complete. G TCP/IP has nothing to do with the problem. I can reproduce the problem  I by suspending the process on the other end or by sitting in the debugger.    glen herrmannsfeldt wrote:   > Jay Olson wrote: > G >> I have a question concerning DECnet task-to-task communications. We  G >> have an application which uses DECnet task-to-task communication to  H >> start up and communicate with some other programs. These programs in H >> turn talk to other systems with TCP/IP. On some days, these programs F >> get busy for some reason (most likely TCP/IP network problems) and J >> they may not get around to reading from the DECnet channel for a while. >  > G >> It appears that the main program can do a $QIOW to send data to the  H >> TCP/IP communication programs and the write will complete before the J >> other end has read the data. In fact, the $QIOW will copmplete even if D >> the other end doesn't have a read active. However, this can only D >> happen a limited number of times, after which the $QIOW does not 4 >> complete until a read is issued on the other end. >  > D > I believe this is a property of most TCP implementations.  Much ofE > the speed advantage of TCP comes from this property.  It seems that @ > it is being passed through to your application, even if DECnet > doesn't have that property.  > 	 > -- glen  >    ------------------------------  + Date: Sat, 17 Jul 2004 06:25:18 +0000 (UTC) 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> M Subject: Re: Do customers need to support DECforms in DECwindows using Motif? 0 Message-ID: <cdagod$huh$1@sparta.btinternet.com>   Hi,   I > Now, if you could make FMS run native in MOTIF, that would be way cool.   L There is/was a FMS to MOTIF interface product developed by DEC in France and+ was available to be purchased by customers.    Regards Richard Maher   8 JF Mezei <jfmezei.spamnot@teksavvy.com> wrote in message& news:40F88565.901906C3@teksavvy.com... > Jack Peacock wrote: G > > Not supporting features that no one uses is hardly a penalty.  Four  years L > > and no complaints is a pretty good indicator that DecForms on DecWindows is6 > > not a significant roadblock to an Itanium upgrade. > L > No, au contraire. It is a pretty good indication that people who are usingL > DECforms are still probably on older versions, stable environments and notK > lokely to upgrade VMS to Alpha or IA64 because their plans are to migrate  to > another platform.  > L > Also, it is my impresison thatr FMS is still far more in use than DECformsK > ever was. DECforms appeared more or less at a time when Palmer started to = > sabotage the company and never had much time to take roots.  >  > I > Now, if you could make FMS run native in MOTIF, that would be way cool.    ------------------------------  % Date: Sat, 17 Jul 2004 05:41:04 +0800 , From: Paul Repacholi <prep@prep.synonet.com> Subject: Re: Is a file open 0 Message-ID: <871xjbk4un.fsf@k9.prep.synonet.com>  , "Karsten Nyblad" <nospam@nospam.com> writes:  ; > "Paul Repacholi" <prep@prep.synonet.com> wrote in message , > news:877jt559kl.fsf@k9.prep.synonet.com...  B >> Get the VCB and then walk the FCB chain looking for the file ofF >> interest. Need kernel mode and to get the locking right. If nothing3 >> else, it makes suporting LKI code look better :)   D > It is much easier to use the ACP QIO interface to assign a channelD > to the file.  Then you use a QIO to get the file statistics block.( > That block holds a pointer to the FCB.  B That will work in a cluster as well. Last time I did it was a COW. (Cluster Of Wun ;)   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------   Date: 17 Jul 2004 12:39:12 GMT* From: rlgoodman@acnospam.org (Roy Goodman) Subject: Re: Is a file open : Message-ID: <Xns952958033780Crlgoodmannyc@199.184.165.239>  # John Santos <JOHN@egh.com> wrote in , <1040716233523.16558B-100000@Ives.egh.com>:    >On 16 Jul 2004, Joe wrote:  > H >> To answer the "what is this for" question - roughly files come into aI >> system that decrypts it, the dumps them on the alpha and then they are F >> to get picked up and processed. Of course it shouldn't be picked up= >> for processing if the file is still "coming across." [...]  >>   > F >Aha!  The old "someone's sending me a file, and I don't want to start5 >processing it until I have the whole thing" problem!  > 9 >Over the years, I've seen two approaches to this.  [...]   K I bet someone could be successful writing/selling a "Patterns in VMS" book.   & Or maybe that's just wishful thinking.  L It's great to see people still discussing [Open]VMS after all these years.  I Especially Hein who probably doesn't remember me from DEC but I remember   him from Notes.   L Roy (who still supports a VAX/VMS V5.5-2 system but spends most of his time  with Java on *IX) Goodman * remove "nospa" from Email address to reply   ------------------------------  % Date: Sat, 17 Jul 2004 05:36:43 +0800 , From: Paul Repacholi <prep@prep.synonet.com>@ Subject: Re: Is it possible to route or tunnel the SCS protocol?0 Message-ID: <87658nk51w.fsf@k9.prep.synonet.com>  * "Ralf van Diesen" <Ralf@nospam.nl> writes:  > > I am trying to figure out if it's possible to tunnel the SCSC > protocol, since SCS can not be routed I must look for a different 8 > solution.  Is there anybody who can help me with this?  B Yes. There was a post years ago from some one who booted a cluster# over dial-up across most of the US.   E I think what you really want to ask is "Is it a good idea? and when?"  A slightly curlier furball!   B BTW, the above assumes you have the requisite a good bridges lyingC around to use. The thing that is the limiter is latency, and how it @ degrades with load. This means stiking anything IP in the middle is almost certain to kill you.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------   Date: 17 Jul 2004 06:21:54 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>) Subject: Re: LOGIN.COM comparison utility ? Message-ID: <DTiotGxQ0bj6-pn2-CdwIxoRJpxDL@dave2_os2.home.ours>   " On Thu, 15 Jul 2004 21:58:54 UTC, < koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:  ^ > In article <04071513171707@dscis6-0.dalsemi.com>, brandon@dalsemi.com (John Brandon) writes:  > > Before I go write my code... > > P > > Does anyone have a utility that will scan all LOGIN.COM on the disks looking/ > > for common characteristics?  Symbols (etc).  > > Q > > I have a legacy system that some dev/admin had the great idea to add the same * > > symbols (etc) to each users LOGIN.COM. > > Q > > My mission is to go out and consolidate these symbols (etc) into the SYLOGIN.  > >  > > Any help is appreciated. > A >    As in search?  You could concatenate and sort all the files.  > D >    It really bugs me when applications used by only some users get >    symbols in SYLOGIN. >   D That"s why we have project-specific login.com"s defined in the UAF. 9 This in turn runs the user's LOGIN last.,  i.e. SYLOGIN,  F Project_LOGIN, user login. It also means we can 'correct breakages' in SYS$LOGIN:LOGIN...   --   Cheers - Dave.   ------------------------------  % Date: Sat, 17 Jul 2004 06:34:34 -0400 3 From: Undisclosed <nomail@dontbeaweaselspammer.com>  Subject: OpenVMS security?0 Message-ID: <AMWdnWKtYYEgnWTdRVn-ig@comcast.com>  F couple of questions from a OpenVMS newbie with a little (real little)  security knowledge.   J 1. OpenVMS is mostly written in a variety of type-safe languages, correct?  H what parts of it are written in C or other type-unsafe languages, since D I heard it also uses small amounts of C? I would assume that the OS 
 kernel is.   also  A 2. In one description of very early VMS security I read, VMS was  G categorized as having too many and too closely linked security levels,  @ thus rendering the benefit from properly applied access control ? granularity useless since one could easily chain several small  J vulnerabilities to do the work that one big one would do on other systems.  G how has this been changed in later versions of VMS, since I heard that  C the criticisms no longer apply? Wasn't there a significant rewrite?   F 3. OpenVMS's native access control would be considered discressionary > (sp..) like Unix's is, correct? Except that it has much finer % granularity (more priviledge levels).   I is there support for a "Trusted VMS" along the lines of Trusted Solaris,  D SELinux, or TrustedBSD using Mandatory Access Control or Multilevel  Security models?  D 4. What is OpenVMS's record against race conditions/TOCTOU (Time of I Check, Time of Use) bugs and other non buffer overflow attacks? How does  ' OpenVMS defend against them in general?   H final note, what the hell is wrong with HP that they won't port OpenVMS  to the damned Opteron?  I I'd love to see more competition in the OS marketplace, and aggressively  E pricing OpenVMS as a solid server while putting it on real commodity  ) hardware might win OVMS a lot more users.    ------------------------------    Date: 17 Jul 2004 07:34:36 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: OpenVMS security?3 Message-ID: <LGbx9+oT1Uh0@eisner.encompasserve.org>   f In article <AMWdnWKtYYEgnWTdRVn-ig@comcast.com>, Undisclosed <nomail@dontbeaweaselspammer.com> writes:  L > 1. OpenVMS is mostly written in a variety of type-safe languages, correct?   Absolutely not. B There is only a tiny bit of Ada in VMS (a few security functions).! There is lots of Bliss and Macro.   J > what parts of it are written in C or other type-unsafe languages, since F > I heard it also uses small amounts of C? I would assume that the OS  > kernel is.  8 The parts in C (not so much on VAX) are the newer parts.  C > 2. In one description of very early VMS security I read, VMS was  I > categorized as having too many and too closely linked security levels,  B > thus rendering the benefit from properly applied access control A > granularity useless since one could easily chain several small  L > vulnerabilities to do the work that one big one would do on other systems.  G The "too many" issue is solved by using the VMS-documented "categories" J of privileges (which I think should be called "levels") for thinking aboutG your privilege assignment task.  Thinking about devour, normal, etc. is  much more reasonable.   I > how has this been changed in later versions of VMS, since I heard that  E > the criticisms no longer apply? Wasn't there a significant rewrite?   E I don't think it is a problem, but one of the hallmarks of VMS in the B operating system world is a committment to backward compatibility.  E There _was_ a significant reworking of the internals of many security 2 functions associated with the release of VMS V6.0.  H > 3. OpenVMS's native access control would be considered discressionary @ > (sp..) like Unix's is, correct? Except that it has much finer ' > granularity (more priviledge levels).  > K > is there support for a "Trusted VMS" along the lines of Trusted Solaris,  F > SELinux, or TrustedBSD using Mandatory Access Control or Multilevel  > Security models?  D There is SEVMS, which was only supported up through V6.2, due mainlyD to lack of customer interest.  Even government agencies dealing withF classified material tend to actually _uses_ System High in their shop,F despite the fact that the NCSC talked a lot about multilevel security.  ' For the record, SEVMS included code for    	The Bell-Lapadula model 	The Biba integrity extensions	 	Labeling   F > 4. What is OpenVMS's record against race conditions/TOCTOU (Time of K > Check, Time of Use) bugs and other non buffer overflow attacks? How does  ) > OpenVMS defend against them in general?   D The record is extremely good, accomplished by strong internal codingD standards.  Probing arguments to system services is quite methodicalC and internal reviews of new code are done by experienced people who + understand the meaning of argument probing.   J > final note, what the hell is wrong with HP that they won't port OpenVMS  > to the damned Opteron?  A VMS development is aimed at architectures capable of use in large  multiprocessor configurations.  K > I'd love to see more competition in the OS marketplace, and aggressively  G > pricing OpenVMS as a solid server while putting it on real commodity  + > hardware might win OVMS a lot more users.   C The HP VMS people keep saying "stay tuned" for Itanium VMS pricing.    ------------------------------  # Date: Sat, 17 Jul 2004 13:28:05 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger)  Subject: Re: OpenVMS security?L Message-ID: <rdeininger-1707040934020001@user-105n8kc.dialup.mindspring.com>  < In article <AMWdnWKtYYEgnWTdRVn-ig@comcast.com>, Undisclosed( <nomail@dontbeaweaselspammer.com> wrote:  G >couple of questions from a OpenVMS newbie with a little (real little)   >security knowledge. > K >1. OpenVMS is mostly written in a variety of type-safe languages, correct?  > I >what parts of it are written in C or other type-unsafe languages, since  E >I heard it also uses small amounts of C? I would assume that the OS   >kernel is.   H The main VMS implementation languages are VAX macro, Bliss, and C.  VeryE roughly, these are used in about equal proportions.  None of these is J type-safe, though both Bliss and C can support reasonably safe programming if used properly.   O Other languanges are used, but they represent a fairly small part of the total.   C Generally, older stuff is Macro and BLISS, newer stuff is mostly C.   G In the original kernel, most of the code was Macro.  Bliss tended to be & used more in outlying parts of the OS.    G Data descriptors are used extensively in VMS, which greatly reduces the E risk inherent in using type-unsafe languages.  VMS is fairly paranoid J about data integrity, but the burden is usually on the programmer, not the	 language.      >also  > B >2. In one description of very early VMS security I read, VMS was H >categorized as having too many and too closely linked security levels, A >thus rendering the benefit from properly applied access control  @ >granularity useless since one could easily chain several small K >vulnerabilities to do the work that one big one would do on other systems.   I I'd like to see an example of this.  Is sounds like nonsense, but perhaps + I don't understand the problem description.   J VMS components can have narrow, well-defined privileges which are tailoredA to specific needs.  There's not much overlap and privileges don't # generally "accumulate" in odd ways.       H >how has this been changed in later versions of VMS, since I heard that D >the criticisms no longer apply? Wasn't there a significant rewrite?  H The main security mechanisms haven't changed much, at least for the lastI 20-odd years.  I never used the first two versions, so I can't comment on  the very early days.    G >3. OpenVMS's native access control would be considered discressionary  ? >(sp..) like Unix's is, correct? Except that it has much finer  & >granularity (more priviledge levels).  3 Yes, standard VMS access control is discressionary.     J >is there support for a "Trusted VMS" along the lines of Trusted Solaris, E >SELinux, or TrustedBSD using Mandatory Access Control or Multilevel   >Security models?   J There is/was secure VMS (SEVMS), which supports mandatory access control. E Not currently a standard product for recent VMS versions, but I think @ there are customers with SEVMS support under custom contracts.     ...   I >final note, what the hell is wrong with HP that they won't port OpenVMS   >to the damned Opteron?   I Probably because it would take a lot of work and money, and nobody inside C or outside HP has shown a convincing business case for such a port.   G I think there are many ways to make VMS more visible, more popular, and F more successful.  I doubt porting to Opteron would be in the top 10 in terms of return on investment.  J Suppose VMS magically appeared on Opteron tomorrow, but nothing else aboutH VMS (features, quality, support, marketing, etc.) changed at all.  Would> you expect a lot of new VMS customers to show up?  I wouldn't.  H I think a lot can be done to help VMS, quicker, cheaper, and easier than porting to Opteron.   J >I'd love to see more competition in the OS marketplace, and aggressively F >pricing OpenVMS as a solid server while putting it on real commodity * >hardware might win OVMS a lot more users.  F Well, if I was in charge I'd try to make VMS dirt cheap on entry-levelG systems.  This is a business decision that's pretty independent of what F hardware VMS runs on.  Alpha, Itanium, or Opteron, the decision on VMS price points would be the same.   H Itanium systems are already going to be way cheaper than Alpha systems. @ Everything needed to make inexpensive VMS solutions will soon be& available, without porting to Opteron.   ------------------------------  % Date: Sat, 17 Jul 2004 07:34:59 -0700 # From: "Tom Linden" <tom@kednos.com>  Subject: RE: OpenVMS security?9 Message-ID: <NDEMLKKEBOIFBMJLCECIOENDDIAA.tom@kednos.com>    < -----Original Message-----> < From: Robert Deininger [mailto:rdeininger@mindspringdot.com]' < Sent: Saturday, July 17, 2004 6:28 AM  < To: Info-VAX@Mvb.Saic.Com   < Subject: Re: OpenVMS security? <  < > < In article <AMWdnWKtYYEgnWTdRVn-ig@comcast.com>, Undisclosed* < <nomail@dontbeaweaselspammer.com> wrote: < H < >couple of questions from a OpenVMS newbie with a little (real little) < >security knowledge. < > 9 < >1. OpenVMS is mostly written in a variety of type-safe  < languages, correct?  < > J < >what parts of it are written in C or other type-unsafe languages, sinceF < >I heard it also uses small amounts of C? I would assume that the OS
 < >kernel is.  < J < The main VMS implementation languages are VAX macro, Bliss, and C.  VeryG < roughly, these are used in about equal proportions.  None of these is L < type-safe, though both Bliss and C can support reasonably safe programming < if used properly.   F There was an exhange recently relating to the extensive use of SDL for OpenVMS,B has OpenVMS engineering ported SDL to Itanium?  If not, will they?   < C < Other languanges are used, but they represent a fairly small part  < of the total.  < E < Generally, older stuff is Macro and BLISS, newer stuff is mostly C.  < I < In the original kernel, most of the code was Macro.  Bliss tended to be ( < used more in outlying parts of the OS. <  < I < Data descriptors are used extensively in VMS, which greatly reduces the G < risk inherent in using type-unsafe languages.  VMS is fairly paranoid L < about data integrity, but the burden is usually on the programmer, not the < language.  <  <  < >also  < > C < >2. In one description of very early VMS security I read, VMS was I < >categorized as having too many and too closely linked security levels, B < >thus rendering the benefit from properly applied access controlA < >granularity useless since one could easily chain several small > < >vulnerabilities to do the work that one big one would do on < other systems. < K < I'd like to see an example of this.  Is sounds like nonsense, but perhaps - < I don't understand the problem description.  < L < VMS components can have narrow, well-defined privileges which are tailoredC < to specific needs.  There's not much overlap and privileges don't % < generally "accumulate" in odd ways.  <  <  < I < >how has this been changed in later versions of VMS, since I heard that F < >the criticisms no longer apply? Wasn't there a significant rewrite? < J < The main security mechanisms haven't changed much, at least for the lastK < 20-odd years.  I never used the first two versions, so I can't comment on  < the very early days. <  < H < >3. OpenVMS's native access control would be considered discressionary@ < >(sp..) like Unix's is, correct? Except that it has much finer( < >granularity (more priviledge levels). < 5 < Yes, standard VMS access control is discressionary.  <  < K < >is there support for a "Trusted VMS" along the lines of Trusted Solaris, F < >SELinux, or TrustedBSD using Mandatory Access Control or Multilevel < >Security models?  < K < There is/was secure VMS (SEVMS), which supports mandatory access control. G < Not currently a standard product for recent VMS versions, but I think @ < there are customers with SEVMS support under custom contracts. <  < ...  < J < >final note, what the hell is wrong with HP that they won't port OpenVMS < >to the damned Opteron?  < K < Probably because it would take a lot of work and money, and nobody inside E < or outside HP has shown a convincing business case for such a port.  < I < I think there are many ways to make VMS more visible, more popular, and H < more successful.  I doubt porting to Opteron would be in the top 10 in  < terms of return on investment. < L < Suppose VMS magically appeared on Opteron tomorrow, but nothing else aboutJ < VMS (features, quality, support, marketing, etc.) changed at all.  Would@ < you expect a lot of new VMS customers to show up?  I wouldn't. < J < I think a lot can be done to help VMS, quicker, cheaper, and easier than < porting to Opteron.  < K < >I'd love to see more competition in the OS marketplace, and aggressively G < >pricing OpenVMS as a solid server while putting it on real commodity , < >hardware might win OVMS a lot more users. < H < Well, if I was in charge I'd try to make VMS dirt cheap on entry-levelI < systems.  This is a business decision that's pretty independent of what H < hardware VMS runs on.  Alpha, Itanium, or Opteron, the decision on VMS! < price points would be the same.  < I < Itanium systems are already going to be way cheaper than Alpha systems. B < Everything needed to make inexpensive VMS solutions will soon be( < available, without porting to Opteron. <  < --- ( < Incoming mail is certified Virus Free.< < Checked by AVG anti-virus system (http://www.grisoft.com).A < Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/2004  <  --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/2004    ------------------------------  % Date: Sat, 17 Jul 2004 11:17:22 -0400 # From: "John Smith" <a@nonymous.com>  Subject: Re: OpenVMS security?, Message-ID: <Hoadnc3EK9GZ3mTdRVn-hg@igs.net>   Robert Deininger wrote: > > In article <AMWdnWKtYYEgnWTdRVn-ig@comcast.com>, Undisclosed* > <nomail@dontbeaweaselspammer.com> wrote: >  <<snip>>    B >> final note, what the hell is wrong with HP that they won't port! >> OpenVMS to the damned Opteron?  > D > Probably because it would take a lot of work and money, and nobody > insideE > or outside HP has shown a convincing business case for such a port.  > E > I think there are many ways to make VMS more visible, more popular,  > and H > more successful.  I doubt porting to Opteron would be in the top 10 in  > terms of return on investment. > F > Suppose VMS magically appeared on Opteron tomorrow, but nothing else > about C > VMS (features, quality, support, marketing, etc.) changed at all.  > Would @ > you expect a lot of new VMS customers to show up?  I wouldn't. > E > I think a lot can be done to help VMS, quicker, cheaper, and easier  > than porting to Opteron.    D Like taking the money an Opeteron port would cost and devoting it to VMS-exclusive advertising?         > > >> I'd love to see more competition in the OS marketplace, andE >> aggressively pricing OpenVMS as a solid server while putting it on ; >> real commodity hardware might win OVMS a lot more users.  > H > Well, if I was in charge I'd try to make VMS dirt cheap on entry-levelD > systems.  This is a business decision that's pretty independent ofF > what hardware VMS runs on.  Alpha, Itanium, or Opteron, the decision > on VMS! > price points would be the same.     = I like your thinking. Maybe we should put you in-charge?  :-)   J If memory serves me correctly, at one point DEC made the statement that itL wanted customers to purchase Alpha running either Tru64 (Digital Unix at theL time) or VMS and wasn't going to place price incentives/disadvantages in theG way - ie. buy a 'base' configuration of OpenVMS/Alpha or the same Alpha K running a 'base' Tru64 config and the price would be the same. Not so under D HP management - there are distinct price disincentives to purchasing OpenVMS.   ------------------------------  % Date: Sat, 17 Jul 2004 12:08:30 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: OpenVMS security?, Message-ID: <40F94EFD.7E155200@teksavvy.com>   Undisclosed wrote:L > 1. OpenVMS is mostly written in a variety of type-safe languages, correct?  J On VMS, there is a common subroutine calling standard which means that youN have routines written in various languages calling routines written in variousK languages. So one language "type safety" becomes irrelevant when it calls a C routine written in a different language with different type safety.   L You may consider "C" to be "unsafe". However, the standard on VMS is that ifL you are writing something that runs below user level privilege (kernel, execD and am not sure about supervisor), then your program doesn't use itsB language's run time library but rather uses system level routines.  A so instead of using "printf", you would use SYS$QIO for instance.   L Also, the issue of buffer overflow for system level code is moot because anyI variable length buffer as passed as a descriptor or equivalent (structure J which contains size of buffer, and routine which returns how many bytes itS wrote in that buffer). So buffer overflows are not an issue for system level stuff.   J And because of a clear separation of user level and exec/kernel code, someK user level code is not allowed to write into exec or kernel memory areas or M even modify code. So if you write some user level C program that purposefully M tries to buffer overflow, it can only mess up its own area and cannot mess up K system level stuff. So worse that can happen is your program aborts with an  access violation.     I Where VMS is vulnerable is the TCPIP stack which was ported from Unix and L which doesn't quite have the robustness that we have come to expect from VMSJ software. The kernel level stuff seems OK, but some of the utilities needsG some reviewing. For instance, there was a switch in the pop server that N allowed its log file to be redirected to another file. The pop server had beenM granted provileges to access anyone's mailbox after authentication, so it had - the provilege to write its log file anywhere.   I So this is not a language related problem. It is a just a design problem.    ------------------------------    Date: 17 Jul 2004 09:43:43 -0700( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: OpenVMS security?= Message-ID: <d7791aa1.0407170843.60f1ecd5@posting.google.com>   k Undisclosed <nomail@dontbeaweaselspammer.com> wrote in message news:<AMWdnWKtYYEgnWTdRVn-ig@comcast.com>... H > couple of questions from a OpenVMS newbie with a little (real little)  > security knowledge.  > H > 3. OpenVMS's native access control would be considered discressionary @ > (sp..) like Unix's is, correct? Except that it has much finer ' > granularity (more priviledge levels).   C Yes, but first redesign and rewrite your unix to cleanly catagorize  and separateF Kernel Mode from Supervisor Mode and from User Mode. Three modes are a minimum D for a correct ring protection system. The use of three or more rings
 happens toC be a fully patented methodology by OpenVMS Engineering. OpenVMS has  four. E OpenVMS also has 40 groups of higher mode functionality classified as 	 requiring  special named privileges.    And, then...  6  - allow access to higher mode services only through a DESCRIPTOR-basedD    calling standard which rules out "by design" the primary cause of securityE    holes - buffer-overflows. The secure Calling Standard is a central  design    theme in OpenVMS.  F  - rewrite and install your TCP/IP stack so that it doesn't live in orB    directly access kernel mode services except through the calling	 standard. @    If the previous condition was met, your tcp/ip stack probablyD    won't work in Supervisor mode or User Mode without these changes.B    This is the reason why most security holes for which OpenVMS isA    affected does not in fact lead to a security vulnerability. In F    this sense I agree with Andrew. Security vulnerability listings are9    innaccurate for OpenVMS. Because they do not correctly 
 differentiate E    whether only a user-mode process can be affected or a higher mode,2D    and whether a higher privilege can be attained. A correct listing>    must rate the severity of the security hole. In OpenVMS the severityE    is usually lower (or meaningless) in comparison to other operatingl    systems.s  F  - design privilege assignments to be attached to a mode. If a programC    installed in a higher mode breaks out to a user-mode prompt. AlleC    privileges assigned during the program run must be automatically  lost.yC    This prevents program privilege tailgating. OpenVMS Hackers (yesi they>    do exist, an admirably persistent if unsuccessful lot) have recently9    discovered this functionality in OpenVMS, inwhich they-
 intentionally F    installed an application with privileges and with a buffer overflow leadingdE    to a DCL prompt. Their experiment failed. This OpenVMS "knockdown"EA    functionality can also be extended to disable the privilege of ?    receiving a DCL Prompt when breaking out of a program or DCLh
 procedure,E    just by assigning the CAPTIVE and RESTRICT flags to user accounts.a  @  - design your Unix to provide only strictly separated (and from overflow?    controlled) user and system stacks to prevent stack crashing  leadingu&    to access to higher mode functions.  F  - 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 OpenVMSdC resulting in a world-beating matrix of Functionality, Reliability,  D Availability, Security, Stability, and Scalability(RT, APMP, SMP andF Cluster). It's an OS that was "Designed" first by 4 competing teams of experts,E and then the best results of these competing design teams merged intoM a ? final design team. They knew of the older Unix, MVS and MulticsC designs, andD naturally they innovated and improved on them for the Enterprise OS  problem space.  A When you are done making these elementary design changes to Unix iA (many of which were intentionally excluded or ignored by the Unix 	 designerscF in 1969 - Multics already had early forms many of them) you will find A most of the commercial products on the Unix Market will no longer  functionF 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 whichp@ "begins" to technically compare with OpenVMS within the frame of	 security.nF And you'll have a product which pays royalties to OpenVMS Engineering.  F Each OS has it's strengths and weaknesses in design and implementationE which will have a different evaluation depending on the problem spacee? it will be applied to, and depending on the design goals of thes
 designers.> For the general Enterprise OS problem space, I believe OpenVMS Engineering ; has most consistently made the best decisions in design ands implementedt? them with an admirably consistent high quality and methodology.s  E OpenVMS enthusiasts can righteously bemoan that the Computer Science  A Profession (Informatics) have failed to recognize and teach theiri studentsC the sophisticated mechanisms and high principals found in OpenVMS, .D preferring instead to favoritize the minimalistic asthetics of Unix,E or the marketing level sophistication in OS selection. This is a realt> loss for enterpise efficiency (money), mission-critical system	 stabilityhF (lives), and the computer science profession (maturity as a science). @ A more balanced and impartial framework of scientific thought is needed. F Computer Science needs some independence from commercial and marketing> interests to even discover the value of many existing designs, technologiesD and ideas. The last major papers over OS design were written over 10/ years ago, but their work is far from complete.   A Critics of OpenVMS should first study and compare it's internals oE (Professional OS comparisons and choices should not be reduced to an eA application layer beauty contest) with an open mind concering OS >> design paradigms, system operations principals and reliability methodologies.A After recovering from the shock, they will likely no longer be as>	 critical.h  E Excuse me. I just noticed I didn't finish writing the last condition.r It should read...   F  - lets also not forget a redesign of the internal logon  mechanism toF    be carried out by one program/process first created at user request andt=    has complete responsibility for the entire login sequence.p  @ By the way, that was not by any means a complete list of OpenVMS, design advantages.  It was only a beginning.  E Excuse me one last time, I have checked my sources and find I need torD change one sentence of my earlier Email. The sentence should read...  =    It's an OS that was "Designed" by experts first producing r>    four design iterations, and then the best results of these ?    designs were carried over into a  final design by "The Blue $    Ribbon Committee".>  C I had thought to have read that the original 4 designs were by fourd@ competing teams, but I can no longer find a source for this. TheE essential message remains unchanged. OpenVMS was carefully "Designed"s( by experienced operating system experts.  E I'm not interested in changing history for any purpose. I do stand byk3 my other statements and opinions made in the email.i     Cheers!h   Keith Cayemberga) IBM Business Services - Hannover, Germanyc   Semi-Nonstandard Disclaimer:3 Any non-official claims concerning my semi-officialf+ opinions are hereby officially disclaimed.    i.e. I said it, not my employer.0 (and no I didn't steal this one from Yogi Berra)  ? I welcome rebuttal, however a lack of response on my part only t> indicates a lack discretionary time to indulge in discussions ' peripheral to my employment activities.    ------------------------------    Date: 17 Jul 2004 09:53:39 -0700( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: OpenVMS security?< Message-ID: <d7791aa1.0407170853.8b380d8@posting.google.com>  k Undisclosed <nomail@dontbeaweaselspammer.com> wrote in message news:<AMWdnWKtYYEgnWTdRVn-ig@comcast.com>...-H > couple of questions from a OpenVMS newbie with a little (real little)  > security knowledge.. > L > 1. OpenVMS is mostly written in a variety of type-safe languages, correct? > J > what parts of it are written in C or other type-unsafe languages, since F > I heard it also uses small amounts of C? I would assume that the OS  > kernel is.  L VMS is/was written in a variety of languages including fortran, pascal, pl1,E bliss, etc.  I believe very little "c" garbage is part of the kernel.sI Because the majority is in bliss which uses descriptors, buffer overflowse are almost non-existent.  iK > is there support for a "Trusted VMS" along the lines of Trusted Solaris, lF > SELinux, or TrustedBSD using Mandatory Access Control or Multilevel  > Security models?  E there is SEVMS or secure vms but that has been phased out because vms @ in general is C2 which I guess suffices for most non-government E installations.  A properly configured vms server placed on the web or @ anywhere in unhackable and virus proof, as defcon9 found out ...  F > 4. What is OpenVMS's record against race conditions/TOCTOU (Time of K > Check, Time of Use) bugs and other non buffer overflow attacks? How does -) > OpenVMS defend against them in general?r  D vms was rated "unhackable" at defcon9 and was never invited back ... does that tell you something?g  J > final note, what the hell is wrong with HP that they won't port OpenVMS  > to the damned Opteron?  C either stupidity ot NIH (not invented here) syndrome, or someone is ? paying them off to keep vms from dominating the market like it c could/should be ...h  K > I'd love to see more competition in the OS marketplace, and aggressively eG > pricing OpenVMS as a solid server while putting it on real commodity g+ > hardware might win OVMS a lot more users.o  C so would all of us vms users, and if vms were properly marketed andtB priced, it would take over the marketplace, that's how good it is!   ------------------------------  % Date: Sat, 17 Jul 2004 11:44:16 -0500n2 From: David J Dachtera <djesys.nospam@comcast.net> Subject: Re: OpenVMS security?+ Message-ID: <40F95760.2B3228D1@comcast.net>]   Undisclosed wrote: > G > couple of questions from a OpenVMS newbie with a little (real little)b > security knowledge.  > L > 1. OpenVMS is mostly written in a variety of type-safe languages, correct? > I > what parts of it are written in C or other type-unsafe languages, since-E > I heard it also uses small amounts of C? I would assume that the OS  > kernel is.  H This is to expand a bit on Larry K.'s answers. He is a security expert - take him very seriously!  G The VMS kernel is mostly a DEC language claled BLISS and VAX Assembler.>B Note that on Alpha, VAX Assembler is actually a 3GL. Some elementsH needed to be Alpha Assembler. I doubt you'll find much, if any, C in the@ kernel code and where you do find it, it conforms to the callingH standards and other structures which eliminate the possibility fo buffer overrun attacks.   > also > : > 2. In one description of very early VMS security I read,  C I'd discard that. Most of "early VMS" has been redeveloped over theh years.  	 > VMS wasoH > categorized as having too many and too closely linked security levels,  & I'd consider that a misinterpretation.  A > thus rendering the benefit from properly applied access control @ > granularity useless since one could easily chain several smallL > vulnerabilities to do the work that one big one would do on other systems.  H Same. "Small vulnerabilities" is open to a great deal of interpretation.G Stated simply, there are some VMS privileges that grant a great deal ofhF access to other privileged areas. Getting privileges you don't have isH challenge, and VMS has been architected very well in this area to ensure( that this cannot be easily accomplished.  H > how has this been changed in later versions of VMS, since I heard thatE > the criticisms no longer apply? Wasn't there a significant rewrite?h  B Yes. VMS today is improved from earlier versions. Having worked onE VAX/VMS V3.2 (which still had RSX-compatibility options), I'd say thenF improvements are substantial enough so as to not be of cencern at this point.  G > 3. OpenVMS's native access control would be considered discressionarya? > (sp..) like Unix's is, correct? Except that it has much finera' > granularity (more priviledge levels).d  @ Not sure what you mean by "privilege levels". VMS has individualG privileges to enable certain functions and/or classes of functions. ForNH object protection, UN*X has three levels: owner group and world. VMS hasE four levels: System, owner, group and world. UN*X has the "superuser"pG (root) and non-privileged types of users. VMS has "system class" users,h9 but also has individual privileges, as mentioned earlier.e  J > is there support for a "Trusted VMS" along the lines of Trusted Solaris,E > SELinux, or TrustedBSD using Mandatory Access Control or Multilevel: > Security models?  H I think that's an "apples to beef" comparison - those other systems haveC security added in as an after-thought, sometimes even a third-partyu< add-in. VMS has security as a criterion of the architecture.  E > 4. What is OpenVMS's record against race conditions/TOCTOU (Time ofrJ > Check, Time of Use) bugs and other non buffer overflow attacks? How does) > OpenVMS defend against them in general?t  / Not sure I can offer anything intelligent here.l  I > final note, what the hell is wrong with HP that they won't port OpenVMSt > to the damned Opteron?  	 <soapbox>n= OpenVMS Engineering has a psychosis about the IA32 and x86-64eG architectures. They go to great lengths to explain why they are so deepsE into denial that IA32 runs "the  world" that one can only wonder whattG trauma they may have suffered, and what therapy it would take to "cure"o them.   H Other than the usual nonsensical blather about "scalable architectures",B there has never been a valid reason put forth for the lack of IA32G support in OpenVMS other than the lack of IRQs in the typical IA32 mobo E design and the dearth of registers in the CPU design. Certainly thereiH are design challenges. Even Itanic has yet to gain the upper hand on theH water pouring through its breached hull, make repairs, right itself, andF sail on to success; yet VMS continues to "bet the farm" on this 64-bitC wanna-be that has yet to leave the gate even after ten years duringaD which time Alpha has achieved commercial data processing success and been struck down in its prime.  J > I'd love to see more competition in the OS marketplace, and aggressivelyF > pricing OpenVMS as a solid server while putting it on real commodity+ > hardware might win OVMS a lot more users.r  7 Manhy of us have been saying that for many, many years:r   http://www.djesys.com/vms/soho/i  
 </soapbox>   -- David J Dachtera dba DJE Systems- http://www.djesys.com/   ------------------------------    Date: 17 Jul 2004 05:27:55 -0700( From: bob@instantwhip.com (Bob Ceculski): Subject: Re: Turn-key OpenVMS E-mail, web server solution?= Message-ID: <d7791aa1.0407170427.3933d321@posting.google.com>d  u Michael Austin <maustin@firstdbasource.com> wrote in message news:<m8TJc.2762$kw4.1668@newssvr22.news.prodigy.com>...? > Bob Ceculski wrote:hz > > Michael Austin <maustin@firstdbasource.com> wrote in message news:<RHAJc.15447$pf3.4440@newssvr24.news.prodigy.com>... > > O > >>Okay, since you seem to think that Purveyor can do anything Apache can do, o > >  > > A > > I'll tell you one thing purveyor can do that apache could notm? > > do for us is run for 5 years now without one single problemr= > > or downtime ... combined with TCPware and OpenVMS it is a  > > bulletproof webserver ...  > Q > I have had a system that ran with apache for almost 2 years (before I left the    J we had apache on tcpware 3 years ago run for two minutes then every minuteJ it needed a reboot because a stupid thing like broken pipes killed it, andK our vp and president are the ones who want to stick with purveyor, not onlyeJ me, because it is rock solid like vms ... as far as learning how to manageH purveyor, I could train my 7 year old son to do that ... and synergy dblE is widely used today on multiple platforms, so it is not very hard toiF find someone, and training them to learn vms is easy ... thats becauseK vms is very user friendly, you should know that!  There is nothing we would H gain by trying so-called new tricks, except downtime and virus warnings!D PHP had a security cert not to long ago, and apache is unix garbage!I So your thesis is full of holes.  Perl and html and cgi and even dlls areeJ still in use today, and are doing quite well ... nope, the only trick thisI old dog needs to know is vms, that alone will put 20 years on a dogs life 	 alone! :)l   ------------------------------    Date: 17 Jul 2004 09:59:08 -0700( From: bob@instantwhip.com (Bob Ceculski) Subject: What could of been ...o= Message-ID: <d7791aa1.0407170859.3870ba7a@posting.google.com>a  : if I owned OpenVMS ... I would bundle it on alpha EV79 and4 EV8 with RDB along with what comes with it now, plus9 TCPware as the IP stack and purveyor as the webserver ...t5 it would be the number one os in the world ... the IT 6 world is crying out for a secure reliable os right now; while paying thru their nose for security and risking theirt8 businesses with downtime while OpenVMS has been doing it8 for over 25 years, and no one knows about it because DEC7 then compaq then HP was too stupid to take advantage ofs  what they have ... what a shame!   ------------------------------   End of INFO-VAX 2004.393 ************************dards.  Probing arguments to system servts ability to provide earnings
growth well into the future. We are maintaining our guidance for 2003
earnings per common share, diluted, at $1.80 to $2.05, excluding the
cumulative effects of new accounting rules related to asset retirement
obligations being implemented in 2003. We will continue making an
important contribution toward building a strong America."</P>
<P>
<H2>    ANNUAL PERFORMANCE SUMMARY</H2>
<P>    Construction Materials and Mining</P>
<P>    Record earnings of $48.7 million were 