On 2022-11-02, IanD <iloveopenvms@gmail.com> wrote:
>
> I would have thought VMS could leverage it's historical reputation in security to give it an advantage against Linux at least, but I'm not convinced it has done enough to ensure it's up to date in the modern security landscape and it really needs to make sure it has it's ducks all in a row and then some because any failure in the security arena could/would end VMS chances of making a comeback

Unfortunately, the idea of VMS security somehow being comparable to
today's expected security standards is utterly delusional.

Even Linux is _far_ in advance of what VMS offers.

For example, Linux has mandatory access controls and VMS is still stuck
back in the DAC world.

There's no ASLR/KASLR support on VMS.

There's nothing like the Unix chroot jails on VMS.

Compiler protections in generated code has been lacking on VMS compared
to what is available elsewhere, but John in recent years has started
looking at getting comparable protections in the VMS compilers, when it
comes to generating code, that currently exist elsewhere.

Back in the 1980s/early 1990s, VMS was a leader in security and it has
proudly remained there while the rest of the world has moved on.

Simon.

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

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley
> via Info-vax
> Sent: Thursday, November 03, 2022 10:42 AM
> To: info-vax@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> Subject: [Info-vax] VMS and security
>
> On 2022-11-02, IanD <iloveopenvms@gmail.com> wrote:
> >
> > I would have thought VMS could leverage it's historical reputation in
> > security to give it an advantage against Linux at least, but I'm not
> > convinced it has done enough to ensure it's up to date in the modern
> > security landscape and it really needs to make sure it has it's ducks
> > all in a row and then some because any failure in the security arena
> > could/would end VMS chances of making a comeback
>
> Unfortunately, the idea of VMS security somehow being comparable to
> today's expected security standards is utterly delusional.
>
> Even Linux is _far_ in advance of what VMS offers.
>
> For example, Linux has mandatory access controls and VMS is still stuck
back
> in the DAC world.
>
> There's no ASLR/KASLR support on VMS.
>
> There's nothing like the Unix chroot jails on VMS.
>
> Compiler protections in generated code has been lacking on VMS compared
> to what is available elsewhere, but John in recent years has started
looking at
> getting comparable protections in the VMS compilers, when it comes to
> generating code, that currently exist elsewhere.
>
> Back in the 1980s/early 1990s, VMS was a leader in security and it has
proudly
> remained there while the rest of the world has moved on.
>
> Simon.
>

For those looking for additional security than what the base OpenVMS OS
provides, they can always add 3rd party products like those from
PointSecure.

Reference: System Detective
<https://pointsecure.com/products/system-detective/>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 11/7/2022 8:30 PM, kemain.nospam@gmail.com wrote:
>
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley
>> via Info-vax
>> Sent: Thursday, November 03, 2022 10:42 AM
>> To: info-vax@rbnsn.com
>> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
>> Subject: [Info-vax] VMS and security
>>
>> On 2022-11-02, IanD <iloveopenvms@gmail.com> wrote:
>>>
>>> I would have thought VMS could leverage it's historical reputation in
>>> security to give it an advantage against Linux at least, but I'm not
>>> convinced it has done enough to ensure it's up to date in the modern
>>> security landscape and it really needs to make sure it has it's ducks
>>> all in a row and then some because any failure in the security arena
>>> could/would end VMS chances of making a comeback
>>
>> Unfortunately, the idea of VMS security somehow being comparable to
>> today's expected security standards is utterly delusional.
>>
>> Even Linux is _far_ in advance of what VMS offers.
>>
>> For example, Linux has mandatory access controls and VMS is still stuck
> back
>> in the DAC world.
>>
>> There's no ASLR/KASLR support on VMS.
>>
>> There's nothing like the Unix chroot jails on VMS.
>>
>> Compiler protections in generated code has been lacking on VMS compared
>> to what is available elsewhere, but John in recent years has started
> looking at
>> getting comparable protections in the VMS compilers, when it comes to
>> generating code, that currently exist elsewhere.
>>
>> Back in the 1980s/early 1990s, VMS was a leader in security and it has
> proudly
>> remained there while the rest of the world has moved on.
>>
>> Simon.
>>
>
> For those looking for additional security than what the base OpenVMS OS
> provides, they can always add 3rd party products like those from
> PointSecure.
>
> Reference: System Detective
> <https://pointsecure.com/products/system-detective/>
>
>
> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com

I don't use Linux, but it is my impression that just about everything in Linux
is from third parties. Nor is Linux restricted to a single vendor.

So why then should VSI be responsible for everything VMS needs?

Gotta love double standards ...

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

On 2022-11-07, <kemain.nospam@gmail.com> <kemain.nospam@gmail.com> wrote:
>
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley
>> via Info-vax
>> Sent: Thursday, November 03, 2022 10:42 AM
>> To: info-vax@rbnsn.com
>> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
>> Subject: [Info-vax] VMS and security
>>
>> Unfortunately, the idea of VMS security somehow being comparable to
>> today's expected security standards is utterly delusional.
>>
>> Even Linux is _far_ in advance of what VMS offers.
>>
>> For example, Linux has mandatory access controls and VMS is still stuck
> back
>> in the DAC world.
>>
>> There's no ASLR/KASLR support on VMS.
>>
>> There's nothing like the Unix chroot jails on VMS.
>>
>> Compiler protections in generated code has been lacking on VMS compared
>> to what is available elsewhere, but John in recent years has started
> looking at
>> getting comparable protections in the VMS compilers, when it comes to
>> generating code, that currently exist elsewhere.
>>
>> Back in the 1980s/early 1990s, VMS was a leader in security and it has
> proudly
>> remained there while the rest of the world has moved on.
>>
>> Simon.
>>
>
> For those looking for additional security than what the base OpenVMS OS
> provides, they can always add 3rd party products like those from
> PointSecure.
>
> Reference: System Detective
><https://pointsecure.com/products/system-detective/>
>

How well does PointSecure handle the above items in my list ?

Simon.

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

On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>
> I don't use Linux, but it is my impression that just about everything in Linux
> is from third parties. Nor is Linux restricted to a single vendor.
>
> So why then should VSI be responsible for everything VMS needs?
>
> Gotta love double standards ...
>

Well that's a load of bollocks David. We are talking about things
that are integral within Linux, in the same way as, say, RMS, clustering,
and KESU modes are integral within VMS.

The only people in a position to add those missing features to VMS are
VSI themselves.

Simon.

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

I raised the security point in the other thread as a possible avenue for VMS to gain a reason for businesses to adopt it because in my experience was being exited from workplaces unless they have some type of stranglehold, typically some type of application, that stops it being migrated off of. That's not a long term winning strategy.

I realise VMS no longer holds the security mantle it once did but rather than try and out-compete Linux and Windows in areas they have won market share in, I thought it would be better to focus VMS energy in an area where VMS could utilise it's existing good name (how behind that image is to reality, is not the point) and build upon it, to potentially leap-frog the others or at least compete with a chance.

How feasible this is as a realistic goal, I have no idea, it just seems a sensible line of reasoning when security breaches are continuing to happen all over the planet and business are more than prepared to throw money towards systems highly focused on security vs trying to get them to adopt an OS that most younger business executive would have no idea about yet alone heard of.

What's the alternative?
You either out-compete Linux and/or Windows that have pretty much conquered the entire IT world, except niche mainframe areas, and I don't see this happening anytime soon, OR you come up with something that puts you on an even playing field / leap-frogs you ahead.

We've got to VMS on x86 and even VM support, that's a start, but it's not the end state or has even made VMS competitive, so what else can be done to give VMS a competitive advantage?

What else would get businesses to adopt VMS into their existing eco systems that they don't already have capabilities for?

Security surely would be one arena because it's cutting edge, always adapting and never a settled solution

Maybe I'm wrong, I'm just putting my ideas forward

On 2022-11-03 13:42:27 +0000, Simon Clubley said:

> On 2022-11-02, IanD <iloveopenvms@gmail.com> wrote:
>>
>> I would have thought VMS could leverage it's historical reputation in
>> security to give it an advantage against Linux at least, but I'm not
>> convinced it has done enough to ensure it's up to date in the modern
>> security landscape and it really needs to make sure it has it's ducks
>> all in a row and then some because any failure in the security arena
>> could/would end VMS chances of making a comeback
>
> Unfortunately, the idea of VMS security somehow being comparable to
> today's expected security standards is utterly delusional.
>
> Even Linux is _far_ in advance of what VMS offers.

Write a secure app with encrypted data storage, with secure key
management, with encrypted and authenticated connections checking
client and server certs, with IPv4 and IPv6 support, integrate the
results with LDAP, and with the OpenVMS system configuration such that
the app won't allow access all over if it's breached (e.g. sandboxing).
If the goals involve writing an app from before Y2K and with older
security requirements, or incrementally updating security in same,
sure, OpenVMS does fine. But... have y'all thought about how much is
missing from the programming concepts manual and the security manual,
and how much of what does exist for documentation is just scattered
around in mostly-unrelated OpenVMS and layered product manuals, or
sometimes in comments in files, or documentation at related websites?
Connecting using public key authentication using common root certs—the
Mozilla server root cert list, for instance—is itself more of a project
than it ever should be. Can this stuff be done with OpenVMS? Sure. But
there are myriad ways to screw it up. Too many subtle ways, too.

--
Pure Personal Opinion | HoffmanLabs LLC

On 11/8/2022 1:29 PM, Simon Clubley wrote:
> On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> I don't use Linux, but it is my impression that just about everything in Linux
>> is from third parties. Nor is Linux restricted to a single vendor.
>>
>> So why then should VSI be responsible for everything VMS needs?
>>
>> Gotta love double standards ...
>>
>
> Well that's a load of bollocks David. We are talking about things
> that are integral within Linux, in the same way as, say, RMS, clustering,
> and KESU modes are integral within VMS.
>
> The only people in a position to add those missing features to VMS are
> VSI themselves.
>
> Simon.
>

Gee Simon, I thought we were talking about security and SSL.

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

On Thursday, November 3, 2022 at 6:42:30 AM UTC-7, Simon Clubley wrote:
> Unfortunately, the idea of VMS security somehow being comparable to
> today's expected security standards is utterly delusional.
>
> Even Linux is _far_ in advance of what VMS offers.
>
> For example, Linux has mandatory access controls and VMS is still stuck
> back in the DAC world.
>
> There's no ASLR/KASLR support on VMS.
>
> There's nothing like the Unix chroot jails on VMS.
>
> Compiler protections in generated code has been lacking on VMS compared
> to what is available elsewhere, but John in recent years has started
> looking at getting comparable protections in the VMS compilers, when it
> comes to generating code, that currently exist elsewhere.

Does VSI have a security program roadmap? I would have hoped that the x64 port would include table-stakes features like ASLR; if the product wants to compete with Linux and Windows, it will also need to have transparency on progress @ modernization features, compiler practices, and responsible security reporting -- at a minimum

On 11/7/2022 11:24 PM, Dave Froble wrote:
> I don't use Linux, but it is my impression that just about everything in
> Linux is from third parties.  Nor is Linux restricted to a single vendor.

I think that depends a lot on whether you talk about Linux
kernel or a typical Linux distro.

The Linux kernel comes with very little.

A typical Linux distro comes with almost everything (open source)
under the sun.

Arne

On 11/8/2022 1:29 PM, Simon Clubley wrote:
> On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>> I don't use Linux, but it is my impression that just about everything in Linux
>> is from third parties. Nor is Linux restricted to a single vendor.
>>
>> So why then should VSI be responsible for everything VMS needs?
>>
>> Gotta love double standards ...
>
> Well that's a load of bollocks David. We are talking about things
> that are integral within Linux, in the same way as, say, RMS, clustering,
> and KESU modes are integral within VMS.

That was pretty strong words given that you are only 75% correct ...

Arne

On 2022-11-08, Dave Froble <davef@tsoft-inc.com> wrote:
> On 11/8/2022 1:29 PM, Simon Clubley wrote:
>> On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> I don't use Linux, but it is my impression that just about everything in Linux
>>> is from third parties. Nor is Linux restricted to a single vendor.
>>>
>>> So why then should VSI be responsible for everything VMS needs?
>>>
>>> Gotta love double standards ...
>>>
>>
>> Well that's a load of bollocks David. We are talking about things
>> that are integral within Linux, in the same way as, say, RMS, clustering,
>> and KESU modes are integral within VMS.
>>
>> The only people in a position to add those missing features to VMS are
>> VSI themselves.
>>
>> Simon.
>>
>
> Gee Simon, I thought we were talking about security and SSL.
>

Although SSL has been discussed previously, SSL wasn't even mentioned in
the list of things I asked about in the posting you are responding to.

I am asking some very awkward questions about the limitations of VMS
internally when compared to Linux and you are trying to move the
discussion away from that and onto other ground.

Simon.

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

On 2022-11-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/8/2022 1:29 PM, Simon Clubley wrote:
>> On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>> I don't use Linux, but it is my impression that just about everything in Linux
>>> is from third parties. Nor is Linux restricted to a single vendor.
>>>
>>> So why then should VSI be responsible for everything VMS needs?
>>>
>>> Gotta love double standards ...
>>
>> Well that's a load of bollocks David. We are talking about things
>> that are integral within Linux, in the same way as, say, RMS, clustering,
>> and KESU modes are integral within VMS.
>
> That was pretty strong words given that you are only 75% correct ...
>

I've just reviewed my list in the posting that David is responding to
and I don't see it, so can you tell me which 25% am I wrong about ?

Thanks,

Simon.

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

On 2022-11-08, jimc...@gmail.com <jimcausey@gmail.com> wrote:
> On Thursday, November 3, 2022 at 6:42:30 AM UTC-7, Simon Clubley wrote:
>> Unfortunately, the idea of VMS security somehow being comparable to
>> today's expected security standards is utterly delusional.
>>
>> Even Linux is _far_ in advance of what VMS offers.
>>
>> For example, Linux has mandatory access controls and VMS is still stuck
>> back in the DAC world.
>>
>> There's no ASLR/KASLR support on VMS.
>>
>> There's nothing like the Unix chroot jails on VMS.
>>
>> Compiler protections in generated code has been lacking on VMS compared
>> to what is available elsewhere, but John in recent years has started
>> looking at getting comparable protections in the VMS compilers, when it
>> comes to generating code, that currently exist elsewhere.
>
> Does VSI have a security program roadmap? I would have hoped that the x64
> port would include table-stakes features like ASLR; if the product wants to
> compete with Linux and Windows, it will also need to have transparency on
> progress @ modernization features, compiler practices, and responsible
> security reporting -- at a minimum

The only security work I have seen is an enhanced password algorithm
and plans for encryption of VMS cluster traffic.

John has also talked about adding some industry-standard security
features to the compilers but I don't know the status of that work.

The last one on your list is especially annoying because VSI _did_
introduce a public reporting mechanism in the immediate aftermath of
my DCL research, but then they removed it for some reason after all
the fuss had died down. :-( :-(

Emails to VSI and requests to VSI via their contact page asking them
to reinstate it have gone ignored.

Simon.

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

On 11/8/2022 7:40 PM, Arne Vajhøj wrote:
> On 11/7/2022 11:24 PM, Dave Froble wrote:
>> I don't use Linux, but it is my impression that just about everything in Linux
>> is from third parties. Nor is Linux restricted to a single vendor.
>
> I think that depends a lot on whether you talk about Linux
> kernel or a typical Linux distro.
>
> The Linux kernel comes with very little.
>
> A typical Linux distro comes with almost everything (open source)
> under the sun.

I think my point was that perhaps not all of that "almost everything" comes from
the same source.

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

On 11/3/2022 9:42 AM, Simon Clubley wrote:
> On 2022-11-02, IanD <iloveopenvms@gmail.com> wrote:
>>
>> I would have thought VMS could leverage it's historical reputation in security to give it an advantage against Linux at least, but I'm not convinced it has done enough to ensure it's up to date in the modern security landscape and it really needs to make sure it has it's ducks all in a row and then some because any failure in the security arena could/would end VMS chances of making a comeback
>
> Unfortunately, the idea of VMS security somehow being comparable to
> today's expected security standards is utterly delusional.

Who's expectations?

> Even Linux is _far_ in advance of what VMS offers.

Perhaps in some areas, and perhaps VMS is ahead in others.

> For example, Linux has mandatory access controls and VMS is still stuck
> back in the DAC world.

Is this the only method?

> There's no ASLR/KASLR support on VMS.

Is this the only method?

> There's nothing like the Unix chroot jails on VMS.

Is this the only method?

> Compiler protections in generated code has been lacking on VMS compared
> to what is available elsewhere, but John in recent years has started
> looking at getting comparable protections in the VMS compilers, when it
> comes to generating code, that currently exist elsewhere.
>
> Back in the 1980s/early 1990s, VMS was a leader in security and it has
> proudly remained there while the rest of the world has moved on.

It is understood that VMS has been neglected by it's owners for some time.
However, the question of how far behind could be interesting.

Simon, you throw out things used elsewhere and claim that that is the only way
to provide security. I don't think that is quite accurate.

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

On 2022-11-09, Dave Froble <davef@tsoft-inc.com> wrote:
> On 11/3/2022 9:42 AM, Simon Clubley wrote:
>> On 2022-11-02, IanD <iloveopenvms@gmail.com> wrote:
>>>
>>> I would have thought VMS could leverage it's historical reputation in security to give it an advantage against Linux at least, but I'm not convinced it has done enough to ensure it's up to date in the modern security landscape and it really needs to make sure it has it's ducks all in a row and then some because any failure in the security arena could/would end VMS chances of making a comeback
>>
>> Unfortunately, the idea of VMS security somehow being comparable to
>> today's expected security standards is utterly delusional.
>
> Who's expectations?
>

Everyone in the industry outside of those who write DEC Basic code for
a living ?

>> Even Linux is _far_ in advance of what VMS offers.
>
> Perhaps in some areas, and perhaps VMS is ahead in others.
>
>> For example, Linux has mandatory access controls and VMS is still stuck
>> back in the DAC world.
>
> Is this the only method?
>

The fact you are asking this question, and phrasing it in this way,
tells me that you simply don't understand the issues being discussed.

Security is a layered approach, and things that were not required 20-30
years ago, are now required (and expected to be available) as a result of
experience and a changing security environment.

>> There's no ASLR/KASLR support on VMS.
>
> Is this the only method?
>

That question makes absolutely no sense.

>> There's nothing like the Unix chroot jails on VMS.
>
> Is this the only method?
>

If you could come up with something that provides the same level of
isolation, that could be acceptable as well. What would be your
suggested VMS alternative to a Unix chroot jail ?

>> Compiler protections in generated code has been lacking on VMS compared
>> to what is available elsewhere, but John in recent years has started
>> looking at getting comparable protections in the VMS compilers, when it
>> comes to generating code, that currently exist elsewhere.
>>
>> Back in the 1980s/early 1990s, VMS was a leader in security and it has
>> proudly remained there while the rest of the world has moved on.
>
> It is understood that VMS has been neglected by it's owners for some time.
> However, the question of how far behind could be interesting.
>
> Simon, you throw out things used elsewhere and claim that that is the only way
> to provide security. I don't think that is quite accurate.
>

Ok, so what are the VMS equivalents of the above functionality that
can be used to address the same security issues ?

I am especially interested in your plans for implementing MAC security
on VMS to the same level of functionality and fine-grained levels of
control seen in SELinux.

Simon.

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

On 2022-11-09 14:01:09 +0000, Dave Froble said:

> On 11/3/2022 9:42 AM, Simon Clubley wrote:
>> On 2022-11-02, IanD <iloveopenvms@gmail.com> wrote:
>>>
>>> I would have thought VMS could leverage it's historical reputation in
>>> security to give it an advantage against Linux at least, but I'm not
>>> convinced it has done enough to ensure it's up to date in the modern
>>> security landscape and it really needs to make sure it has it's ducks
>>> all in a row and then some because any failure in the security arena
>>> could/would end VMS chances of making a comeback
>>
>> Unfortunately, the idea of VMS security somehow being comparable to
>> today's expected security standards is utterly delusional.
>
> Who's expectations?

The expectations of folks with some experience with securing and
isolating apps and data on various available systems, of course.

>> Even Linux is _far_ in advance of what VMS offers.
>
> Perhaps in some areas, and perhaps VMS is ahead in others.

Clustering and host-based RAID-1 is still pretty good, but few OpenVMS
folks use that due to its pricing. And other platforms have
alternatives to those.

>> For example, Linux has mandatory access controls and VMS is still stuck
>> back in the DAC world.
>
> Is this the only method?

Traditional mandatory access control (MAC) security isn't widely used.
Some of the concepts from MAC security were repurposed, and are used.
OpenVMS does have MAC features, though many of the related tools were
retired with the old layered product. The MAC features could be the
foundation for better app isolation. Some of the MAC features have
served well underneath sandboxes and jails, and underneath containers.
Subsystem identifiers and the latent bits of MAC can be used to build
your own isolation scheme, but that all gets Really Ugly. And none of
that restricts available calls past what privileges might be involved;
BSD-style pledges or such, and unveil. https://man.openbsd.org/pledge
https://man.openbsd.org/unveil.2 etc.

>> There's no ASLR/KASLR support on VMS.
>
> Is this the only method?

It's one of the more common means of making exploitation more unstable.
Pointer authentication is another. The two can and variously are
combined.

>> There's nothing like the Unix chroot jails on VMS.
>
> Is this the only method?

Sandboxes and jails are the typical means, and BSD-style promises can
get part way there. These mechanisms also tend to be the foundation of
containers.

>> Compiler protections in generated code has been lacking on VMS compared
>> to what is available elsewhere, but John in recent years has started
>> looking at getting comparable protections in the VMS compilers, when it
>> comes to generating code, that currently exist elsewhere.
>>
>> Back in the 1980s/early 1990s, VMS was a leader in security and it has
>> proudly remained there while the rest of the world has moved on.
>
> It is understood that VMS has been neglected by it's owners for some
> time. However, the question of how far behind could be interesting.

Fairly far behind, yes.

> Simon, you throw out things used elsewhere and claim that that is the
> only way to provide security. I don't think that is quite accurate.

An install that's running isolated is a possibility, though the
traditional means of trying to prevent app and system
compromises—writing totally mistake-free code—has proven somewhat
problematic.

--
Pure Personal Opinion | HoffmanLabs LLC

On 11/9/2022 9:01 AM, Dave Froble wrote:
> On 11/3/2022 9:42 AM, Simon Clubley wrote:
>> On 2022-11-02, IanD <iloveopenvms@gmail.com> wrote:
>>> I would have thought VMS could leverage it's historical reputation in
>>> security to give it an advantage against Linux at least, but I'm not
>>> convinced it has done enough to ensure it's up to date in the modern
>>> security landscape and it really needs to make sure it has it's ducks
>>> all in a row and then some because any failure in the security arena
>>> could/would end VMS chances of making a comeback
>>
>> Unfortunately, the idea of VMS security somehow being comparable to
>> today's expected security standards is utterly delusional.
>
> Who's expectations?

Whoever are into IT security today.

>> Even Linux is _far_ in advance of what VMS offers.
>
> Perhaps in some areas, and perhaps VMS is ahead in others.

The lack of investments in VMS the last 25 years has some
consequences.

Security has evolved a lot in those 25 years, so VMS
are generally behind in this area.

>> For example, Linux has mandatory access controls and VMS is still stuck
>> back in the DAC world.
>
> Is this the only method?
>
>> There's no ASLR/KASLR support on VMS.
>
> Is this the only method?
>
>> There's nothing like the Unix chroot jails on VMS.
>
> Is this the only method?

It is nice features for security.

None of them are strictly required.

VMS will not need all security features available elsewhere, but
VMS will definitely need a good portion of them to be considered
OK.

> It is understood that VMS has been neglected by it's owners for some
> time. However, the question of how far behind could be interesting.

I will claim that the VMS team anno 1990 could catch up in a year
or two, but VSI will need way more years to catch up. They are a
small team and even though security is important then they also have
lots of other priorities.

> Simon, you throw out things used elsewhere and claim that that is the
> only way to provide security.  I don't think that is quite accurate.

The cheapest and fastest way forward for VSI is to build
on work other have done.

Security research coming up with new ideas and concepts are
bloody expensive. DEC had the money for it. VSI doesn't.

Arne

On 11/9/2022 1:30 PM, Simon Clubley wrote:
> On 2022-11-09, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 11/3/2022 9:42 AM, Simon Clubley wrote:
>>> On 2022-11-02, IanD <iloveopenvms@gmail.com> wrote:
>>>>
>>>> I would have thought VMS could leverage it's historical reputation in security to give it an advantage against Linux at least, but I'm not convinced it has done enough to ensure it's up to date in the modern security landscape and it really needs to make sure it has it's ducks all in a row and then some because any failure in the security arena could/would end VMS chances of making a comeback
>>>
>>> Unfortunately, the idea of VMS security somehow being comparable to
>>> today's expected security standards is utterly delusional.
>>
>> Who's expectations?
>
> Everyone in the industry outside of those who write DEC Basic code for
> a living ?

Lots of people has or still does live from writing Basic code.

>>> There's nothing like the Unix chroot jails on VMS.
>>
>> Is this the only method?
>>
>
> If you could come up with something that provides the same level of
> isolation, that could be acceptable as well. What would be your
> suggested VMS alternative to a Unix chroot jail ?

>> It is understood that VMS has been neglected by it's owners for some time.
>> However, the question of how far behind could be interesting.
>>
>> Simon, you throw out things used elsewhere and claim that that is the only way
>> to provide security. I don't think that is quite accurate.
>
> Ok, so what are the VMS equivalents of the above functionality that
> can be used to address the same security issues ?
>
> I am especially interested in your plans for implementing MAC security
> on VMS to the same level of functionality and fine-grained levels of
> control seen in SELinux.

MAC for VMS should be relative well understood. That was what
SEVMS provided.

For isolation I am thinking that VMS got group isolation
on global sections, logicals, file access and process
access. Adding group isolation to disk mount and
network definition plus adding a group based
scheduler may start to look like a foundation for
something.

Arne

On 11/9/2022 8:55 AM, Dave Froble wrote:
> On 11/8/2022 7:40 PM, Arne Vajhøj wrote:
>> On 11/7/2022 11:24 PM, Dave Froble wrote:
>>> I don't use Linux, but it is my impression that just about everything
>>> in Linux
>>> is from third parties.  Nor is Linux restricted to a single vendor.
>>
>> I think that depends a lot on whether you talk about Linux
>> kernel or a typical Linux distro.
>>
>> The Linux kernel comes with very little.
>>
>> A typical Linux distro comes with almost everything (open source)
>> under the sun.
>
> I think my point was that perhaps not all of that "almost everything"
> comes from the same source.

That would be hundreds/thousands of open source projects.

Some of that stuff could work on VMS as well.

But VMS has a huge handicap compared to Linux - the
interest in the VMS community to contribute to
open source is very small.

Arne

On 2022-11-09 22:07:00 +0000, John Dallman said:

> An equivalent of chroot would require setting up new tables of symbols
> and logicals. I don't know enough about VMS internals to know how
> complicated that would be.

Complicated.

I looked into that a while back.

That whole area gets "entertaining", as OpenVMS assumes a whole bunch
of stuff is system-wide, as do a number of apps and app installers, and
assumptions can get broken.

Logical names and tables, global sections, event flag clusters, IP
ports, mailboxes, and usernames, for instance.

Some of that can be "demoted" to a sandbox with (maybe) more logical
name tables for each sandbox, some—like potentially permitting
duplicate usernames and duplicate identifiers and UICs—gets more gnarly.

Symbols are already inherently process local, so those are less of an issue.

The BSD Pledge scheme is rather more feasible on a smaller budget and
with fewer repercussions, and apps can opt into that. VSI probably
doesn't have the budget or the schedule or the call for an overhaul of
the scale of adding sandboxes.

--
Pure Personal Opinion | HoffmanLabs LLC

On 11/9/2022 8:09 AM, Simon Clubley wrote:
> On 2022-11-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/8/2022 1:29 PM, Simon Clubley wrote:
>>> On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> I don't use Linux, but it is my impression that just about everything in Linux
>>>> is from third parties. Nor is Linux restricted to a single vendor.
>>>>
>>>> So why then should VSI be responsible for everything VMS needs?
>>>>
>>>> Gotta love double standards ...
>>>
>>> Well that's a load of bollocks David. We are talking about things
>>> that are integral within Linux, in the same way as, say, RMS, clustering,
>>> and KESU modes are integral within VMS.
>>
>> That was pretty strong words given that you are only 75% correct ...
>>
>
> I've just reviewed my list in the posting that David is responding to
> and I don't see it, so can you tell me which 25% am I wrong about ?

Really?

So if we from that list:

# For example, Linux has mandatory access controls and VMS is still stuck
# back in the DAC world.
# # There's no ASLR/KASLR support on VMS.
# # There's nothing like the Unix chroot jails on VMS.
# # Compiler protections in generated code has been lacking on VMS compared
# to what is available elsewhere, but John in recent years has started
# looking at getting comparable protections in the VMS compilers, when it
# comes to generating code, that currently exist elsewhere.

create a little pop quiz:

Which of the following items:
A) mandatory access controls
B) ASLR
C) chroot jails
D) Compiler protections in generated code
are not "integral within Linux"?

Then you have no idea?

Arne

On 2022-11-09, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> Traditional mandatory access control (MAC) security isn't widely used.

One place where a form of MAC security is in wide use is in protecting
server-side applications in Linux. SELinux is turned on by default, and
with a configuration that protects server applications, such as Apache,
unless you actively decide to turn it off.

In the early days of SELinux, there was an attempt to cover much more than
that by default, but that was considered to be too much out of the box, so
the default coverage was changed to server applications only.

Simon.

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

On 2022-11-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/9/2022 8:09 AM, Simon Clubley wrote:
>> On 2022-11-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/8/2022 1:29 PM, Simon Clubley wrote:
>>>> On 2022-11-07, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>> I don't use Linux, but it is my impression that just about everything in Linux
>>>>> is from third parties. Nor is Linux restricted to a single vendor.
>>>>>
>>>>> So why then should VSI be responsible for everything VMS needs?
>>>>>
>>>>> Gotta love double standards ...
>>>>
>>>> Well that's a load of bollocks David. We are talking about things
>>>> that are integral within Linux, in the same way as, say, RMS, clustering,
>>>> and KESU modes are integral within VMS.
>>>
>>> That was pretty strong words given that you are only 75% correct ...
>>>
>>
>> I've just reviewed my list in the posting that David is responding to
>> and I don't see it, so can you tell me which 25% am I wrong about ?
>
> Really?
>
> So if we from that list:
>
> # For example, Linux has mandatory access controls and VMS is still stuck
> # back in the DAC world.
> #
> # There's no ASLR/KASLR support on VMS.
> #
> # There's nothing like the Unix chroot jails on VMS.
> #
> # Compiler protections in generated code has been lacking on VMS compared
> # to what is available elsewhere, but John in recent years has started
> # looking at getting comparable protections in the VMS compilers, when it
> # comes to generating code, that currently exist elsewhere.
>
> create a little pop quiz:
>
> Which of the following items:
> A) mandatory access controls
> B) ASLR
> C) chroot jails
> D) Compiler protections in generated code
> are not "integral within Linux"?
>
> Then you have no idea?
>

They all are present and integrated within Linux these days Arne. Which one
do you think is missing from Linux ?

BTW, that last one, where the entire Linux distribution is built with
those protections, has generally been present in Linux distributions
for the last decade or so. It's probably going to be the first one in the
above list to be present on VMS, at least after John does the necessary
compiler and other work (including dealing with the Macro-32 problem).

Having a VMS distribution with all the binaries compiled with the expected
industry-standard protections such as stack-smashing protection, will be a
nice thing to finally see.

Simon.

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