[Info-vax] Questions and observations about OpenVMS

[Dave Froble]

On 3/7/2021 4:31 AM, Simon Clubley wrote:
> On 2021-03-07, Dave Froble <davef at tsoft-inc.com> wrote:
>> Well shit!!!!
>>
>> It's time to counter some of Simon's favorite topics.  Again!
>>
>> I hate it when that happens ....
>>
>
> I am only responding to the OP's rather naive view of the state
> of VMS security. This time, I did not start this. :-)
>
>> On 3/7/2021 3:27 AM, Simon Clubley wrote:
>>> On 2021-03-06, Forrest Aldrich <forrie at forrie.com> wrote:
>>>>
>>>> OpenVMS's idea of security (ie: concentric circles, operate with just
>>>> what is needed) makes a ton of sense to me.  We don't hear about VMS
>>>> being hacked or riddled with malware.
>>>>
>>>
>>> People have answered your other questions. I will focus on this part.
>>>
>>> VMS security is very lacking compared to what is standard these days.
>>
>> "Standard" sort of depends upon several things, including "definition",
>> right?
>>
>
> There's a reason why the phrase "industry standard" exists.

Oh, this one gave me a good chuckle.  It's so Intel could assign that 
label to the itanic.  We all know how that worked out.

>>> From a strictly security point of view, VMS does not have 4 modes, it
>>> only has 2 modes.
>>
>> Who cares?
>>
>
> Everyone, including the OP, who seems to think that VMS needing 4 modes
> makes it more secure. If VMS had been designed to take proper advantage
> of those 4 modes, it could very well have been. Unfortunately, it wasn't.
>
>>> From a security point of view, it has a user mode and a single inner
>>> mode with the single inner mode split over 3 hardware modes.
>>>
>>> Once in any of the inner modes you can get to any other inner mode
>>> without any additional privileges required.
>>>
>>> VMS is lacking other security features considered to be standard
>>> these days, such as ASLR and a mandatory access control environment.
>>
>> See above concerning "standard".
>>
>
> See above regarding the phrase "industry standard". :-)

See above concerning "itanic".  :-)  :-)

>>> The way a process survives multiple images (which can be both a mixture
>>> of privileged and non-privileged images) is a weakness. A Unix-style
>>> approach, where a process is created to run a new image, would be
>>> a more secure approach.
>>
>> Proof?
>>
>
> CVE-2017-17482.
>
>>> There is a good deal of inertia in the VMS world and a desire in some
>>> quarters to carry on doing something because that is the way it has
>>> always been done.
>>
>> If it works, don't fix it.
>>
>
> Just because something _appears_ to still work, it doesn't mean that
> a better way hasn't been invented in the mean time.

In general I agree.  But that doesn't mean re-building the entire planet 
every time something new is developed.

>>> For example, DECnet Phase IV is totally unsuited
>>> for today's world, but VSI has already been forced to port it to x86-64
>>> VMS, even with other work outstanding, because it is still used by so
>>> many people.

"IF" DECnet still does the required job, and "IF" there is no 
possibility of security breaches, then is still is "suited" for that 
particular job.  U_nder such a situation, suggesting someone rip out 
what they have and replace it is what is "unsuitable".  It's real easy 
to spend other people's money.

>> Since humans haven't yet come up with "counter-grav", the wheel is still
>> in use, and will be for the foreseeable future.
>>
>
> But humans _have_ come up with the networking protocol versions of future
> technology (future been defined as when DECnet Phase IV was invented) which
> are much more secure than DECnet Phase IV.
>
>>> As for VMS not been hacked, you really, really should not have gone there. :-)
>>>
>>> VMS has the dubious honour of hosting one of the world's longest
>>> surviving operating system vulnerabilities (it survived for 33 years
>>> before it was discovered). It was confirmed to be exploitable on
>>> both VAX and Alpha and it is an open question whether someone familiar
>>> with the Itanium environment could have created a variant of the exploit
>>> to do something bad there.
>>
>> Oh, give me a break!  How long are you going to polish that particular
>> apple?  It was a bug in a utility, which has been fixed.
>>
>
> Actually, I had decided to let it rest as mentioned the last time
> I pushed it. I only mentioned it again due to the OP's comments and
> his rather naive take on the state of VMS security.
>
> BTW, it was ultimately a bug in DCL itself.
>
>>> Supervisor mode shells (ie: DCL) have access to the privileges of
>>> the programs they run. This is not a good thing.
>>
>> So use one that doesn't ....
>>
>
> Yes, I agree. :-) It would indeed be nice if supervisor mode shells
> were not a thing on VMS. Unfortunately, that is not going to happen
> any time in the near future.
>
> Simon.
>


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486