[Info-vax] Questions and observations about OpenVMS

[Simon Clubley]

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.

>> 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". :-)

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

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

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.