VMS and security

[Simon Clubley]

On 2022-11-02, IanD <iloveo...@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.

[kemain...@gmail.com]

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

[Dave Froble]

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: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Simon Clubley]

On 2022-11-07, <kemain...@gmail.com> <kemain...@gmail.com> wrote:
>
>> -----Original Message-----
>> From: Info-vax <info-vax...@rbnsn.com> On Behalf Of Simon Clubley
>> via Info-vax
>> Sent: Thursday, November 03, 2022 10:42 AM
>> To: info...@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 Clubley]

On 2022-11-07, Dave Froble <da...@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.

[IanD]

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

[Stephen Hoffman]

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

> On 2022-11-02, IanD <iloveo...@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

[Dave Froble]

On 11/8/2022 1:29 PM, Simon Clubley wrote:
> On 2022-11-07, Dave Froble <da...@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.

[jimc...@gmail.com]

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

[Arne Vajhøj]

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

[Arne Vajhøj]

On 11/8/2022 1:29 PM, Simon Clubley wrote:

> On 2022-11-07, Dave Froble <da...@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

[Simon Clubley]

On 2022-11-08, Dave Froble <da...@tsoft-inc.com> wrote:
> On 11/8/2022 1:29 PM, Simon Clubley wrote:
>> On 2022-11-07, Dave Froble <da...@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 Clubley]

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 Clubley]

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.

[Dave Froble]

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

[Dave Froble]

On 11/3/2022 9:42 AM, Simon Clubley wrote:
> On 2022-11-02, IanD <iloveo...@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.

[Simon Clubley]

On 2022-11-09, Dave Froble <da...@tsoft-inc.com> wrote:
> On 11/3/2022 9:42 AM, Simon Clubley wrote:
>> On 2022-11-02, IanD <iloveo...@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.

[Stephen Hoffman]

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

[Arne Vajhøj]

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

[Arne Vajhøj]

On 11/9/2022 1:30 PM, Simon Clubley wrote:
> On 2022-11-09, Dave Froble <da...@tsoft-inc.com> wrote:
>> On 11/3/2022 9:42 AM, Simon Clubley wrote:
>>> On 2022-11-02, IanD <iloveo...@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

[Arne Vajhøj]

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

[John Dallman]

In article <tkh0tn$j43$1...@gioia.aioe.org>, ar...@vajhoej.dk (Arne Vajhøj)
wrote:

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

When people are making decisions to adopt a new OS, having familiar
security mechanisms available definitely makes it easier. ASLR and KASLR
are fairly simple, but they need to be implemented in the OS loader to
work properly, so they're definitely VSI's job.

Some compiler protections should be available via the LLVM native
back-end.

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.

John

[Stephen Hoffman]

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.

[Arne Vajhøj]

On 11/9/2022 8:09 AM, Simon Clubley wrote:
> On 2022-11-08, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 11/8/2022 1:29 PM, Simon Clubley wrote:
>>> On 2022-11-07, Dave Froble <da...@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

[Simon Clubley]

On 2022-11-09, Stephen Hoffman <seao...@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 Clubley]

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.

[Arne Vajhøj]

Well - maybe you are not aware.

But the compiler used by Linux GCC is not "integral within Linux"
(your words) but "from third parties" (Davids words). It comes
from the GNU project not the Linux kernel project.

That a compiler is used to build something does not make it
an integral part of what is being build.

MSVC++ is not an integral part of MS Excel even though
it is used to build it.

Arne

[Simon Clubley]

A review of my posting history, including discussion of work I have
done on them in the past, would make it very clear I know this.
However, you have moved from talking about the compiler protections
to talking about the compilers themselves.

> That a compiler is used to build something does not make it
> an integral part of what is being build.
>

No, but the resulting compiler protections _ARE_ an integral part of
Linux just as I stated above. Note that I never stated anything about
the compilers themselves above, but only the resulting protections.

You end up with a Linux system that has yet another layer of security
integrated right into it, which makes it harder to compromise, in exactly
the same way as ASLR and friends also make it harder to compromise.

Basic protections BTW that are missing from "the world's most secure
operating system."

[Arne Vajhøj]

I know that you have a high opinion about yourself.

> However, you have moved from talking about the compiler protections
> to talking about the compilers themselves.

The code generated by the compiler is certainly different from the
compiler itself.

But the first comes from the second.

>> That a compiler is used to build something does not make it
>> an integral part of what is being build.
>
> No, but the resulting compiler protections _ARE_ an integral part of
> Linux just as I stated above. Note that I never stated anything about
> the compilers themselves above, but only the resulting protections.

A Linux binary compiled with GCC using the compile switch that
enable SSP has this feature.

But it is the third party product GCC that makes it possible.

It is not a characteristics of Linux. It is the benefit of the
third party tooling available for Linux.

Arne

[Simon Clubley]

Well, that's extremely rich coming from you Arne.

You have such a self-important opinion of yourself that you can confidently
state, on a wide range of subjects, that people are doing one of A, B, or C
and then assign percentages to those options and then you further state this
level of detail as if it was an established fact.

The sheer sense of self-importance of someone who feels comfortable doing
that on a regular basis easily dwarfs anything I may be guilty of.

>> However, you have moved from talking about the compiler protections
>> to talking about the compilers themselves.
>
> The code generated by the compiler is certainly different from the
> compiler itself.
>
> But the first comes from the second.
>
>>> That a compiler is used to build something does not make it
>>> an integral part of what is being build.
>>
>> No, but the resulting compiler protections _ARE_ an integral part of
>> Linux just as I stated above. Note that I never stated anything about
>> the compilers themselves above, but only the resulting protections.
>
> A Linux binary compiled with GCC using the compile switch that
> enable SSP has this feature.
>
> But it is the third party product GCC that makes it possible.
>
> It is not a characteristics of Linux. It is the benefit of the
> third party tooling available for Linux.
>

It's more than that. Linux is now developed with those options enabled
so errors are much more likely to be caught during development and testing.

Based on what has happened in the past, I very strongly suspect that if
VSI ever get around to adding this functionality to its own VMS builds,
the first thing it will find are a range of coding issues and potential
security issues that have simply not been picked up until now.

This is a good thing and will help increase the quality of VMS.

[Steve Kelley]

On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne Vajhøj wrote:
> But VMS has a huge handicap compared to Linux - the
> interest in the VMS community to contribute to
> open source is very small.
>
> Arne

And until there is free access to VMS in some form (is there ever really going to be a community license for x86?), the interest in the open source community to contribute to VMS is going to be nonexistent.

One big difference between VMS and Linux -- Linux doesn't charge people to become developers.

[Arne Vajhøj]

On 11/21/2022 2:31 PM, Steve Kelley wrote:
> On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne Vajhøj wrote:
>> But VMS has a huge handicap compared to Linux - the
>> interest in the VMS community to contribute to
>> open source is very small.
>

> And until there is free access to VMS in some form (is there ever
> really going to be a community license for x86?), the interest in the
> open source community to contribute to VMS is going to be nonexistent.
>
> One big difference between VMS and Linux -- Linux doesn't charge people to become developers.

One can get community license for Alpha and Itanium. Used Alpha boxes
are rather cheap. There is a free open source Alpha emulator available.
I expect community license for x86-64 to become available
at some point in time (maybe when native compilers become
available).

One can get the student license with an Alpha emulator.

One can get ISV license for Alpha, Itanium or x86-64.

One can get an account on DECUS Eisner.

I really don't see cost as something stopping those wanting
to contribute to open source on VMS.

Arne

[Robert A. Brooks]

On 11/21/2022 2:31 PM, Steve Kelley wrote:

Neither do we -- ISV partnership at the bronze level is free

https://vmssoftware.com/about/partners/program/


--
--- Rob

[Phillip Helbig (undress to reply)]

In article <647a7286-58e6-45fa...@googlegroups.com>,

Steve Kelley <smk...@gmail.com> writes:

> On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne Vajhøj wrote:
> > But VMS has a huge handicap compared to Linux - the
> > interest in the VMS community to contribute to
> > open source is very small.
> >
> > Arne
>
> And until there is free access to VMS in some form (is there ever really
> going to be a community license for x86?), the interest in the open source
> community to contribute to VMS is going to be nonexistent.

Maybe not nonexistent, but much less.

> One big difference between VMS and Linux -- Linux doesn't charge people to
> become developers.

I was really optimistic when VSI took over VMS, but their license policy
will probably kill it.

[Phillip Helbig (undress to reply)]

In article <tlgnmt$1p5j$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=

<ar...@vajhoej.dk> writes:

> On 11/21/2022 2:31 PM, Steve Kelley wrote:

> > On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne VajhÞj wrote:
> >> But VMS has a huge handicap compared to Linux - the
> >> interest in the VMS community to contribute to
> >> open source is very small.
> >

> > And until there is free access to VMS in some form (is there ever
> > really going to be a community license for x86?), the interest in the
> > open source community to contribute to VMS is going to be nonexistent.
> >
> > One big difference between VMS and Linux -- Linux doesn't charge people to become developers.
>

> One can get community license for Alpha and Itanium. Used Alpha boxes
> are rather cheap. There is a free open source Alpha emulator available.
> I expect community license for x86-64 to become available
> at some point in time (maybe when native compilers become
> available).
>
> One can get the student license with an Alpha emulator.
>
> One can get ISV license for Alpha, Itanium or x86-64.
>
> One can get an account on DECUS Eisner.
>
> I really don't see cost as something stopping those wanting

> to contribute to open source on VMS.

For the future we are concerned with VSI VMS on Itanium. Even a
hobbyist will probably not be willing to invest much time, effort, or
money for a license which might stop working less than a year from now.

[Phillip Helbig (undress to reply)]

In article <tlgqhi$3q5k2$1...@dont-email.me>, "Robert A. Brooks"

<FIRST...@vmssoftware.com> writes:

> On 11/21/2022 2:31 PM, Steve Kelley wrote:

> > On Wednesday, November 9, 2022 at 3:25:23 PM UTC-5, Arne VajhÞj wrote:
> >> But VMS has a huge handicap compared to Linux - the interest in the VMS
> >> community to contribute to open source is very small.
> >>
> >> Arne
> >
> > And until there is free access to VMS in some form (is there ever really
> > going to be a community license for x86?), the interest in the open source
> > community to contribute to VMS is going to be nonexistent.
> >
> > One big difference between VMS and Linux -- Linux doesn't charge people to
> > become developers.
>

> Neither do we -- ISV partnership at the bronze level is free
>
> https://vmssoftware.com/about/partners/program/

Do the licenses expire one year after creation?

[Simon Clubley]

On 2022-11-22, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>
> For the future we are concerned with VSI VMS on Itanium. Even a
> hobbyist will probably not be willing to invest much time, effort, or
> money for a license which might stop working less than a year from now.
>

In a world where people produce emulations of hardware architectures just
for fun, it's interesting that no-one has produced a full-system Itanium
emulator.

That shows just how complex Itanium really is. (Plus the fact that the
required firmware is now only apparently available under a support contract).

[John Dallman]

In article <tlihd4$3h94$1...@dont-email.me>,

clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> In a world where people produce emulations of hardware
> architectures just for fun, it's interesting that no-one
> has produced a full-system Itanium emulator.
>
> That shows just how complex Itanium really is.

There's usually an element of nostalgia in the motive to start an
emulation project. I really doubt anyone who has experience of work on
Itanium at the instruction-by-instruction level views it as a fun time
that they want to recapture. A few months of that turned me from a
moderate enthusiast into a profound sceptic, convinced that it was doomed.


John

[Dave Froble]

Community licenses are a year to year thing. Live with it.

ISV licenses are a year to year thing. Live with it.

You get what you pay for. When it is free, the license granter is free to set
the terms.

Now, should you wish to purchase a commercial x86 VMS license, make your offer
to VSI, with your desired terms. If you haven't done so, then you cannot say
you are disappointed.

[Phillip Helbig (undress to reply)]

In article <tlj0jd$4qu4$1...@dont-email.me>, Dave Froble

<da...@tsoft-inc.com> writes:

> >> Neither do we -- ISV partnership at the bronze level is free
> >>
> >> https://vmssoftware.com/about/partners/program/
> >
> > Do the licenses expire one year after creation?
>

> Community licenses are a year to year thing. Live with it.
>
> ISV licenses are a year to year thing. Live with it.
>
> You get what you pay for. When it is free, the license granter is
> free to set the terms.

The HUGE difference is that, in the past, there was always the option to
purchases a full, commercial, non-expiring license. That is no longer
the case.

> Now, should you wish to purchase a commercial x86 VMS license, make your
> offer to VSI, with your desired terms. If you haven't done so, then you
> cannot say you are disappointed.

Many people have, and were disappointed.

[Dave Froble]

On 11/22/2022 2:18 PM, Phillip Helbig (undress to reply) wrote:
> In article <tlj0jd$4qu4$1...@dont-email.me>, Dave Froble
> <da...@tsoft-inc.com> writes:
>
>>>> Neither do we -- ISV partnership at the bronze level is free
>>>>
>>>> https://vmssoftware.com/about/partners/program/
>>>
>>> Do the licenses expire one year after creation?
>>
>> Community licenses are a year to year thing. Live with it.
>>
>> ISV licenses are a year to year thing. Live with it.
>>
>> You get what you pay for. When it is free, the license granter is
>> free to set the terms.
>
> The HUGE difference is that, in the past, there was always the option to
> purchases a full, commercial, non-expiring license. That is no longer
> the case.

That was then, this is now. Things change.

>> Now, should you wish to purchase a commercial x86 VMS license, make your
>> offer to VSI, with your desired terms. If you haven't done so, then you
>> cannot say you are disappointed.
>
> Many people have, and were disappointed.
>

Have you? If not, then you really don't know.

[Arne Vajhøj]

It seems very likely that most CL will be for Alpha
today and hopefully soon x86-64.

Itanium hardware will be too rare.

But I don't think it matters much from an VMS open
source perspective.

If the open source supports VMS Alpha and eventually
VMS x86-64, then it will most likely also work fine on
VMS Itanium.

"VMS is VMS"

Arne

[Stephen Hoffman]

On 2022-11-22 19:38:19 +0000, Dave Froble said:

> On 11/22/2022 2:18 PM, Phillip Helbig (undress to reply) wrote:
>> In article <tlj0jd$4qu4$1...@dont-email.me>, Dave Froble
>> <da...@tsoft-inc.com> writes:
>>
>> The HUGE difference is that, in the past, there was always the option
>> to purchases a full, commercial, non-expiring license. That is no
>> longer the case.
>
> That was then, this is now. Things change.

Yes, times and licencing and the rest can and do change.

Here's another change:

https://www.intel.com/content/www/us/en/products/docs/ondemand/overview.html

How widely (and how quickly) that change might be implemented?

[kemain...@gmail.com]

As a fyi, VSI's open source web page: (great improvements)
<https://vmssoftware.com/products/list/?license=Open%20Source>

A WIP, but some good stuff .e.g. PHP V8
<https://vmssoftware.com/products/php/>


Regards,

Kerry Main
Kerry dot main at starkgaming dot com






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

[ultr...@gmail.com]

On Wednesday, November 9, 2022 at 3:22:04 PM UTC-5, Arne Vajhøj wrote:
> >>
> MAC for VMS should be relative well understood. That was what
> SEVMS provided.
>

> Arne

Since the SEVMS code is still there, wouldn't making sure that code still works and fixing what doesn't be a good and
inexpensive way to start?

[Simon Clubley]

What makes you think its still there, at least in any way that is
remotely usable ?

Even if it was still usable, it still doesn't have anywhere near the
level of functionality that SELinux has. For example, SEVMS has _no_
TCP/IP integration whereas SELinux does, and in ways that actively
enhance the ability of Linux systems to help keep a successful breach
contained.

[Stephen Hoffman]

On 2023-01-03 17:49:54 +0000, ultr...@gmail.com said:

> On Wednesday, November 9, 2022 at 3:22:04 PM UTC-5, Arne Vajhøj wrote:
>>>>
>> MAC for VMS should be relative well understood. That was what SEVMS provided.
>

> Since the SEVMS code is still there, wouldn't making sure that code
> still works and fixing what doesn't be a good and
> inexpensive way to start?

If you want just the underpinnings of Rainbow-era US DoD/NCSC Class B1
Orange-focused MAC, a design which was found approximately non-sellable
including to some of those same entities that had worked on and
specified Class B1 security, and that probably also involving with few
or none of the SEVMS utilities and tools available, and all that also
probably untested for a quarter-century, sure.

Serving as a foundation for a whole lot of design and development work
both on the MAC code and within on OpenVMS APIs and docs and elsewhere,
and within IP networking, and with related work on better-integrated
encryption and key stores and such, sure.

As anything that'll be likely useful by apps in the rest of this decade, no.

Pragmatically, BSD pledge is probably a better option for VSI in the
short term. And that's no small project. And that requires app
assistance. https://man.openbsd.org/pledge.2 Creating app sandboxing
/ app jail / would be the closest modern application, and some parts of
Class B1 might be (poorly) useable for that.

The only folks that might consider NCSC Class B1 Rainbow-era MAC
nowadays are scarce at best, or folks that may have never even used
Class B1 and will probably then quickly lose interest. Managing and
labeling information flow within a large and complex system is less
than easy. And again, Class B1 really isn't all that useful for
securing most apps. Approximately no commercial providers would
consider using Class B1, absent some regulatory or contractual mandate.

[ultr...@gmail.com]

that is where you hire some coal miners and add that code ...

[ultr...@gmail.com]

you just got done telling us it might serve as a basis to add sandboxing and some other features ...

[Stephen Hoffman]

On 2023-01-06 01:17:20 +0000, ultr...@gmail.com said:

> you just got done telling us it might serve as a basis to add
> sandboxing and some other features ...

If you missed the paragraph ending in "sure", sure.