On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
> On 1/24/2024 8:13 AM, Simon Clubley wrote:
>> On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> What is really rude is talking about Linux on c.o.v ...
>>>
>>
>> Unless you consider VMS to be perfect and not in need of any improvement,
>> other operating systems offer some good ideas that it would be nice to
>> see in VMS, especially around security and internal isolation in general.
>>
>
> Then discuss the ideas and concepts ...
>

OK.

A random sample of things from Linux/Unix I would like to see in VMS:

Mandatory Access Controls (my preference) or jails (Stephen's preference).

A shell with decent modern functionality such as:

Proper command history retention and merging from multiple sessions
Easy searching of command history
Tab completion
Editing long command lines
Globbing

Proper package management and management of updates.

Loadable and unloadable kernel modules, with device driver/filesystem/etc
functionality available from within these modules.

ASLR and KASLR support.

Proper timezone management. (Everything is always UTC based, and your
timezone is merely a local session property with no effect on the
on-disk timestamps).

The last one is policy-based, not technical:

A vendor that has proper security reporting mechanisms.

Does anyone have any others to add to the list ?

Simon.

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

In article <uotn92$2ais1$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/24/2024 8:13 AM, Simon Clubley wrote:
>>> On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> What is really rude is talking about Linux on c.o.v ...
>>>>
>>>
>>> Unless you consider VMS to be perfect and not in need of any improvement,
>>> other operating systems offer some good ideas that it would be nice to
>>> see in VMS, especially around security and internal isolation in general.
>>>
>>
>> Then discuss the ideas and concepts ...
>>
>
>OK.
>
>A random sample of things from Linux/Unix I would like to see in VMS:
>
>Mandatory Access Controls (my preference) or jails (Stephen's preference).
>
>A shell with decent modern functionality such as:
>
> Proper command history retention and merging from multiple sessions
> Easy searching of command history
> Tab completion
> Editing long command lines
> Globbing
>
>Proper package management and management of updates.
>
>Loadable and unloadable kernel modules, with device driver/filesystem/etc
>functionality available from within these modules.
>
>ASLR and KASLR support.
>
>Proper timezone management. (Everything is always UTC based, and your
>timezone is merely a local session property with no effect on the
>on-disk timestamps).
>
>The last one is policy-based, not technical:
>
>A vendor that has proper security reporting mechanisms.
>
>Does anyone have any others to add to the list ?

Some sort of userspace pluggable filesystem support.
FUSE, 9P + a mount driver, whatever.

- Dan C.

On 1/25/2024 8:21 AM, Simon Clubley wrote:
> A random sample of things from Linux/Unix I would like to see in VMS:
>
> Mandatory Access Controls (my preference) or jails (Stephen's preference).

The market want containers.

I suspect that means Hoff jails with a marketing label of "container"
instead of "jail".

>
> A shell with decent modern functionality such as:
>
> Proper command history retention and merging from multiple sessions
> Easy searching of command history
> Tab completion
> Editing long command lines
> Globbing

+better control structures
+better data types

But I doubt it makes sense business wise.

VMS got:
* DCL for backwards compatibility
* GNV bash for *nix compatibility
* Python and Perl for more programmatic scripting

Even though DCL2 or XDCL would be nice then I don't think it
will increase VMS sale.

> Proper package management

Traditional Linux package management at the OS level would
be the wrong path. The result is a mess.

The right approach is package management at the application level.

maven, nuget, pypi, npm, composer etc. not yum, dnf etc..

For managing the truly OS stuff relative little is needed. PCSI2
or XPCSI.

> and management of updates.

An option for more automated updates of VMS would be nice.

> Loadable and unloadable kernel modules, with device driver/filesystem/etc
> functionality available from within these modules.

Nice.

But again I doubt it will increase VMS sale.

> ASLR and KASLR support.

That would probably come as part of ongoing security enhancements
at some point in time.

> Proper timezone management. (Everything is always UTC based, and your
> timezone is merely a local session property with no effect on the
> on-disk timestamps).

Nice but tricky to implement without breaking stuff.

Arne

On 1/25/2024 10:31 AM, Dan Cross wrote:
> Some sort of userspace pluggable filesystem support.
> FUSE, 9P + a mount driver, whatever.

That would also be nice.

But how many potential VMS users will consider "userspace
pluggable filesystem support" important in decision process?

I suspect: practically none.

Arne

=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>On 1/25/2024 10:31 AM, Dan Cross wrote:
>> Some sort of userspace pluggable filesystem support.
>> FUSE, 9P + a mount driver, whatever.
>
>That would also be nice.
>
>But how many potential VMS users will consider "userspace
>pluggable filesystem support" important in decision process?

On production systems, I don't think it's all that useful for users to
be able to mount and dismount filesystems, or to install their own new
filesystem drivers of their own design.

I -do- think that there is some security benefit in having the filesystem
support in user space, but I also think the performance penalty is usually
not worth it.

What -would- be useful would be the ability to plug new filesystems easily
into the kernel, along with ntfs and various fat drivers supplied as needed.
Do I need to be able to do this dynamically from user space? Not really.
--scott

On 2024-01-25 20:20:09 +0000, Arne Vajhøj said:

> On 1/25/2024 8:21 AM, Simon Clubley wrote:
>> A random sample of things from Linux/Unix I would like to see in VMS:
>>
>> Mandatory Access Controls (my preference) or jails (Stephen's preference).
>
> The market want containers.
>
> I suspect that means Hoff jails with a marketing label of "container"
> instead of "jail".

Jails / sandboxes can be used as a component of containers, but—as I've
commented elsewhere—containers are far too reminiscent of licensing
arbitrage. Which can somewhat dampen vendor enthusiasm.

Getting a working jail / sandbox on OpenVMS is no small project, both
for VSI, and for the app developers adopting jails / sandboxes.

Still involved but smaller in scope would be some variation of the
pledge(2) mechanism. An aeon or two ago, I'd discussed that and the
related trade-offs with a then-VSI developer. Deets:
https://man.openbsd.org/pledge.2

What OpenVMS traditionally implements as system-wide stuff like
usernames doesn't map all that well.

Jails / sandboxes can be built upon some of the parts of mandatory
access controls, but I ~never want to have to use a system configured
for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.

>
>> A shell with decent modern functionality such as:
>>
>> Proper command history retention and merging from multiple sessions
>> Easy searching of command history
>> Tab completion
>> Editing long command lines
>> Globbing
>
> +better control structures
> +better data types
>
> But I doubt it makes sense business wise.
>
> VMS got:
> * DCL for backwards compatibility
> * GNV bash for *nix compatibility
> * Python and Perl for more programmatic scripting
>
> Even though DCL2 or XDCL would be nice then I don't think it will
> increase VMS sale.

Likely not perceived as an increase sales. Though as happened with DII
COE, sometimes major customers will establish requirements here.

There are a lot of things in this same general category too, which is
the other side of facilitating and encouraging new adoptions.

>> Proper package management
>
> Traditional Linux package management at the OS level would
> be the wrong path. The result is a mess.

OpenVMS packaging and installation is already a spectacular mess, but
then I'm in a charitable mood today.

And the packaging ties into installation, upgrades, removal, app
isolation, startup, shutdown, code-signing, and jails / sandboxes.
Among other areas.

And any new scheme will have to contend with apps arriving via cargo,
nix, pip, cpan, or another installation system, as well.

> The right approach is package management at the application level.
>
> maven, nuget, pypi, npm, composer etc. not yum, dnf etc..
>
> For managing the truly OS stuff relative little is needed. PCSI2 or XPCSI.
>
> > and management of updates.
>
> An option for more automated updates of VMS would be nice.

It'll be nice to implement some of the many features that have become
common in the years since the existing 1988-era designs, yes.

>
>> Loadable and unloadable kernel modules, with device
>> driver/filesystem/etc functionality available from within these modules.
>
> Nice.
>
> But again I doubt it will increase VMS sale.
>
>> ASLR and KASLR support.
>
> That would probably come as part of ongoing security enhancements at
> some point in time.

Stack canaries might be easier.

>> Proper timezone management. (Everything is always UTC based, and your
>> timezone is merely a local session property with no effect on the
>> on-disk timestamps).
>
> Nice but tricky to implement without breaking stuff.

That's been the compatibility hobgoblin ~forever. The quadword format
is embedded all over the place. For some sites, switching to UTC as the
base works fine.

I've run OpenVMS servers set to UTC at various installations, too,
("Oh, that? Yeah. The server is in England." usually suffices.)

Downside is that saved dates can be off by a day pending a rewrite,
which can absolutely be a non-starter for some sites.

PS: The discussion of ASLR/KASLR and buffer-overflow protections
reminds me of this XPM exploit (whether it also hits XBM?) recently
discovered:
https://jfrog.com/blog/xorg-libx11-vulns-cve-2023-43786-cve-2023-43787-part-two/

--
Pure Personal Opinion | HoffmanLabs LLC

On 1/25/2024 6:59 PM, Stephen Hoffman wrote:
> On 2024-01-25 20:20:09 +0000, Arne Vajhøj said:
>> On 1/25/2024 8:21 AM, Simon Clubley wrote:
>>> Mandatory Access Controls (my preference) or jails (Stephen's
>>> preference).
>>
>> The market want containers.
>>
>> I suspect that means Hoff jails with a marketing label of "container"
>> instead of "jail".
>
> Jails / sandboxes can be used as a component of containers, but—as I've
> commented elsewhere—containers are far too reminiscent of licensing
> arbitrage. Which can somewhat dampen vendor enthusiasm.

"containers" is what sells.

> Jails / sandboxes can be built upon some of the parts of mandatory
> access controls, but I ~never want to have to use a system configured
> for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.

SEVMS-style MAC was targeting the 1980's requirements.

>>> A shell with decent modern functionality such as:
>>>
>>>     Proper command history retention and merging from multiple sessions
>>>     Easy searching of command history
>>>     Tab completion
>>>     Editing long command lines
>>>     Globbing
>>
>> +better control structures
>> +better data types
>>
>> But I doubt it makes sense business wise.
>>
>> VMS got:
>> * DCL for backwards compatibility
>> * GNV bash for *nix compatibility
>> * Python and Perl for more programmatic scripting
>>
>> Even though DCL2 or XDCL would be nice then I don't think it will
>> increase VMS sale.
>
> Likely not perceived as an increase sales. Though as happened with DII
> COE, sometimes major customers will establish requirements here.
>
> There are a lot of things in this same general category too, which is
> the other side of facilitating and encouraging new adoptions.

Very few people work at the command prompt today. I doubt "shell power"
will become a requirement.

>>> ASLR and KASLR support.
>>
>> That would probably come as part of ongoing security enhancements at
>> some point in time.
>
> Stack canaries might be easier.

I believe LLVM support it, so ...

>>> Proper timezone management. (Everything is always UTC based, and your
>>> timezone is merely a local session property with no effect on the
>>> on-disk timestamps).
>>
>> Nice but tricky to implement without breaking stuff.
>
> That's been the compatibility hobgoblin ~forever.  The quadword format
> is embedded all over the place. For some sites, switching to UTC as the
> base works fine.
>
> I've run OpenVMS servers set to UTC at various installations, too, ("Oh,
> that? Yeah. The server is in England." usually suffices.)
>
> Downside is that saved dates can be off by a day pending a rewrite,
> which can absolutely be a non-starter for some sites.

For backwards compatibility the old saying applies:

"I'll be damned if I do, I'll be damned if I don't"

Arne

On 26/01/2024 00:18, Arne Vajhøj wrote:

> Very few people work at the command prompt today. I doubt "shell power"
> will become a requirement.
>

Not sure that is true. MS Servers don't have a GUI, Most Linux servers
are installed without a GUI

GUI is for userspace

--
Chris

Den 2024-01-26 kl. 12:45, skrev Chris Townley:
> On 26/01/2024 00:18, Arne Vajhøj wrote:
>
>> Very few people work at the command prompt today. I doubt "shell power"
>> will become a requirement.
>>
>
> Not sure that is true. MS Servers don't have a GUI, Most Linux servers are
> installed without a GUI
>
> GUI is for userspace
>

I think that, what Arne ment, was that very few users are working at the OS
level at all today. Most are application-users and couldn't care les about
how the base system is managed.

Personally, I see little value in/payback from investments in DCL.

On 1/26/2024 6:45 AM, Chris Townley wrote:
> On 26/01/2024 00:18, Arne Vajhøj wrote:
>> Very few people work at the command prompt today. I doubt "shell power"
>> will become a requirement.
>
> Not sure that is true. MS Servers don't have a GUI, Most Linux servers
> are installed without a GUI

System managers (what the rest of the world tend to call sys admins)
and developers frequently use command prompt and scripting.

But the end users do not. They may rely on something on the VMS
system, but they do not work with DCL and the vast majority
of them do not even know what DCL is. Heck - some of them may
never have seen a command prompt on any OS.

Arne

On 2024-01-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/25/2024 6:59 PM, Stephen Hoffman wrote:
>> Jails / sandboxes can be built upon some of the parts of mandatory
>> access controls, but I ~never want to have to use a system configured
>> for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.
>
> SEVMS-style MAC was targeting the 1980's requirements.
>

When I talk about MAC, I am talking about SELinux style MAC, not SEVMS.

I've read the public SEVMS documentation and it is way too limiting for
today's world. SELinux fits right in however. One of the things I like
about SELinux is just how fine-grained and how wide-ranging the control
is. For example, you can allow a service to make outgoing TCP connections
on some ports and deny it access to everything other TCP port.

That way, even if the service gets compromised, the shellcode _still_
can't make an outgoing connection on any TCP port the service has been
denied access to.

Simon.

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

On 1/26/2024 8:16 AM, Simon Clubley wrote:
> On 2024-01-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/25/2024 6:59 PM, Stephen Hoffman wrote:
>>> Jails / sandboxes can be built upon some of the parts of mandatory
>>> access controls, but I ~never want to have to use a system configured
>>> for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.
>>
>> SEVMS-style MAC was targeting the 1980's requirements.
>
> When I talk about MAC, I am talking about SELinux style MAC, not SEVMS.
>
> I've read the public SEVMS documentation and it is way too limiting for
> today's world. SELinux fits right in however. One of the things I like
> about SELinux is just how fine-grained and how wide-ranging the control
> is. For example, you can allow a service to make outgoing TCP connections
> on some ports and deny it access to everything other TCP port.
>
> That way, even if the service gets compromised, the shellcode _still_
> can't make an outgoing connection on any TCP port the service has been
> denied access to.

Is that even MAC? Elsewhere it is called a software firewall.

It is certainly a well known feature. Windows also got it.

In theory it does enhance security. With no other mitigations
in place it can prevent some problems. Like Log4Shell.

But I don't know about how much impact it has in real life.
Secure servers are already behind a firewall that by default
blocks, so outgoing traffic is blocked. And users of
not-so-secure PC's tend to open ports when asked without
thinking.

Arne

On 1/25/2024 8:21 AM, Simon Clubley wrote:
> On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/24/2024 8:13 AM, Simon Clubley wrote:
>>> On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> What is really rude is talking about Linux on c.o.v ...
>>>>
>>>
>>> Unless you consider VMS to be perfect and not in need of any improvement,
>>> other operating systems offer some good ideas that it would be nice to
>>> see in VMS, especially around security and internal isolation in general.
>>>
>>
>> Then discuss the ideas and concepts ...
>>
>
> OK.

I've been reading the posts on this topic for a while. What I think is that any
such ideas and concepts might need to be divided into two categories, 1)
workstation/user interface/development/etc, and 2) production. And so, some
comments.

> A random sample of things from Linux/Unix I would like to see in VMS:
>
> Mandatory Access Controls (my preference) or jails (Stephen's preference).
>
> A shell with decent modern functionality such as:
>
> Proper command history retention and merging from multiple sessions
> Easy searching of command history
> Tab completion
> Editing long command lines
> Globbing

Here is where I have to ask, what is the actual worth of the above, and is it
worth doing?

For any production system, is any of the above helpful? I'd say not helpful.
On any production system, normal operations would all be in command files.
Never anything that required some person to come into work and start or modify
any processes. After all, what happens to production in such an implementation
when that person gets run over by a bus?

Would the above be useful in a workstation/user interface/development and such
system? Absolutely. Is VSI in any position to devote resources to such?
Absolutely not. Took years for the x86 port, which is still not complete.

Be a bit reasonable Simon ...

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

Chris Townley <news@cct-net.co.uk> wrote:
>On 26/01/2024 00:18, Arne Vajhøj wrote:
>
>> Very few people work at the command prompt today. I doubt "shell power"
>> will become a requirement.
>
>Not sure that is true. MS Servers don't have a GUI, Most Linux servers
>are installed without a GUI
>
>GUI is for userspace

Unfortunately it is true. I have met a lot of Microsoft-Trained Windows
Experts who have no real understanding of powershell and who either just
type in commands that they have been given or use a gui tool that sends
powershell commands to the remote machine.

However, I do not think this state of affairs is good. In fact I think it
is probably the one thing most likely to destroy our computer infrastructure
today. So I think that having better and more powerful shells is very
important, but I also think that teaching people to use them is just as
important.

The nice thing about bash is that there are a lot of good training resources
out there. When I was learning DCL there were some wonderful grey training
manuals too. Times have changed, though.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2024-01-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/26/2024 8:16 AM, Simon Clubley wrote:
>> On 2024-01-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 1/25/2024 6:59 PM, Stephen Hoffman wrote:
>>>> Jails / sandboxes can be built upon some of the parts of mandatory
>>>> access controls, but I ~never want to have to use a system configured
>>>> for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.
>>>
>>> SEVMS-style MAC was targeting the 1980's requirements.
>>
>> When I talk about MAC, I am talking about SELinux style MAC, not SEVMS.
>>
>> I've read the public SEVMS documentation and it is way too limiting for
>> today's world. SELinux fits right in however. One of the things I like
>> about SELinux is just how fine-grained and how wide-ranging the control
>> is. For example, you can allow a service to make outgoing TCP connections
>> on some ports and deny it access to everything other TCP port.
>>
>> That way, even if the service gets compromised, the shellcode _still_
>> can't make an outgoing connection on any TCP port the service has been
>> denied access to.
>
> Is that even MAC? Elsewhere it is called a software firewall.
>

Yes, it absolutely is. It's part of the SELinux policy and has nothing
to do with the internal firewall that Linux systems also have.

It's just that SELinux has access to a _wide_ range of objects to control,
not just the traditional file-based access you may be familiar with from
older MAC systems, and a TCP port is just another internal object that
can be controlled by the SELinux policy, including your own extensions
to that policy.

> It is certainly a well known feature. Windows also got it.
>
> In theory it does enhance security. With no other mitigations
> in place it can prevent some problems. Like Log4Shell.
>
> But I don't know about how much impact it has in real life.
> Secure servers are already behind a firewall that by default
> blocks, so outgoing traffic is blocked.
>

That's one of the reasons it's part of a MAC policy, standalone from
any external firewall. The next outgoing connection from the shellcode
might be to a port on IP address 127.0.0.1 as part of a chained attack
so that external firewall never sees that connection attempt.

For anyone unfamiliar with SELinux, I just found this document that gives
a top-level overview of it. I wish VMS had something like this:

https://access.redhat.com/solutions/7032454

Simon.

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

On 2024-01-26, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Be a bit reasonable Simon ...
>

Mandatory Access Controls or jails can absolutely be a _direct_ part of
a production environment.

I also notice you left out all the other things in my list. They can also
be a direct part of a production environment. :-)

I am being reasonable, and the list is a very reasonable list for
production environments.

Simon.

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

In article <uounal$fvn$1@panix1.panix.com>, <kludge@panix.com> wrote:
>=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
>>On 1/25/2024 10:31 AM, Dan Cross wrote:
>>> Some sort of userspace pluggable filesystem support.
>>> FUSE, 9P + a mount driver, whatever.
>>
>>That would also be nice.
>>
>>But how many potential VMS users will consider "userspace
>>pluggable filesystem support" important in decision process?
>
>On production systems, I don't think it's all that useful for users to
>be able to mount and dismount filesystems, or to install their own new
>filesystem drivers of their own design.

Perhaps. I worked on a system where applications were delivered
to prod as small ext4 filesystems that were accessed read-only
via iSCSI and mounted into a container with a ramfs overlay for
temporary files.

Such arrangements are common at e.g. hyperscalers.

>I -do- think that there is some security benefit in having the filesystem
>support in user space, but I also think the performance penalty is usually
>not worth it.

There's a fair amount of prior art here that shows decent
performance. Plan 9, for example, implemented the window system
as a file system. For that matter, the graphics device was
exposed as a filesystem as well, though that was in the kernel.

>What -would- be useful would be the ability to plug new filesystems easily
>into the kernel, along with ntfs and various fat drivers supplied as needed.
>Do I need to be able to do this dynamically from user space? Not really.

YMMV. It's been my experience that once you go down the route
of allowing it, however, you find surprising application areas
and it's actually very useful.

Enough to wrangle new customers? No, not likely.

- Dan C.

On Fri, 26 Jan 2024 08:07:21 -0500, Arne Vajhøj wrote:

> ... some [users] may never have seen a command prompt on any OS.

Might be becoming more common on Windows
<https://www.theregister.com/2024/01/12/microsoft_update_for_bitlocker_vuln/>.

On 1/26/2024 1:41 PM, Simon Clubley wrote:
> On 2024-01-26, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Be a bit reasonable Simon ...
>>
>
> Mandatory Access Controls or jails can absolutely be a _direct_ part of
> a production environment.

Agreed ...

> I also notice you left out all the other things in my list. They can also
> be a direct part of a production environment. :-)

That's because I was only addressing those ideas that would usually be
applicable in a non-production environment.

> I am being reasonable, and the list is a very reasonable list for
> production environments.
>
> Simon.
>

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

Simon Clubley formulated the question :
> On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/24/2024 8:13 AM, Simon Clubley wrote:
>>> On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> What is really rude is talking about Linux on c.o.v ...
>>>>
>>>
>>> Unless you consider VMS to be perfect and not in need of any improvement,
>>> other operating systems offer some good ideas that it would be nice to
>>> see in VMS, especially around security and internal isolation in general.
>>>
>>
>> Then discuss the ideas and concepts ...
>>
>
> OK.
>
> A random sample of things from Linux/Unix I would like to see in VMS:
>
> Mandatory Access Controls (my preference) or jails (Stephen's preference).
>
> A shell with decent modern functionality such as:
>
> Proper command history retention and merging from multiple sessions
> Easy searching of command history
> Tab completion
> Editing long command lines
> Globbing
>
> Proper package management and management of updates.
>
> Loadable and unloadable kernel modules, with device driver/filesystem/etc
> functionality available from within these modules.
>
> ASLR and KASLR support.
>
> Proper timezone management. (Everything is always UTC based, and your
> timezone is merely a local session property with no effect on the
> on-disk timestamps).
>
> The last one is policy-based, not technical:
>
> A vendor that has proper security reporting mechanisms.
>
> Does anyone have any others to add to the list ?
>
> Simon.

Yes. Some kind of automatic disaster recovery. That is, if a process,
or a set of processes, run on a system that crashes, those processes
are
automatically restarted on another cluster member, transparently, with
no manual intervention, and continue from the point they were at when
the system crashed. No transaction lost of any kind, and without having
to add anything in the code that those processes are running. The
operating system (or layered product) does all the work transparently.
Should work with code written 30 years ago, with ACMS applications,
anything.

--
Marc Van Dyck

On 1/28/2024 8:25 AM, Marc Van Dyck wrote:
> Simon Clubley formulated the question :
>> Does anyone have any others to add to the list ?
>
> Yes. Some kind of automatic disaster recovery. That is, if a process,
> or a set of processes, run on a system that crashes, those processes are
> automatically restarted on another cluster member, transparently, with
> no manual intervention, and continue from the point they were at when
> the system crashed. No transaction lost of any kind, and without having
> to add anything in the code that those processes are running. The
> operating system (or layered product) does all the work transparently.
> Should work with code written 30 years ago, with ACMS applications,
> anything.

Something like Tandem NonStop lock-step?

Arne

Arne Vajhøj wrote on 28/01/2024 :
> On 1/28/2024 8:25 AM, Marc Van Dyck wrote:
>> Simon Clubley formulated the question :
>>> Does anyone have any others to add to the list ?
>>
>> Yes. Some kind of automatic disaster recovery. That is, if a process,
>> or a set of processes, run on a system that crashes, those processes are
>> automatically restarted on another cluster member, transparently, with
>> no manual intervention, and continue from the point they were at when
>> the system crashed. No transaction lost of any kind, and without having
>> to add anything in the code that those processes are running. The
>> operating system (or layered product) does all the work transparently.
>> Should work with code written 30 years ago, with ACMS applications,
>> anything.
>
> Something like Tandem NonStop lock-step?
>
> Arne

Indeed. But not with the 30 years old look...

--
Marc Van Dyck

On 1/28/2024 8:32 AM, Arne Vajhøj wrote:
> On 1/28/2024 8:25 AM, Marc Van Dyck wrote:
>> Simon Clubley formulated the question :
>>> Does anyone have any others to add to the list ?
>>
>> Yes. Some kind of automatic disaster recovery. That is, if a process,
>> or a set of processes, run on a system that crashes, those processes are
>> automatically restarted on another cluster member, transparently, with
>> no manual intervention, and continue from the point they were at when
>> the system crashed. No transaction lost of any kind, and without having
>> to add anything in the code that those processes are running. The
>> operating system (or layered product) does all the work transparently.
>> Should work with code written 30 years ago, with ACMS applications,
>> anything.
>
> Something like Tandem NonStop lock-step?
>
> Arne
>
>

Well, no, not really. What I'd envision would be what I'd call an application
monitor, for lack of a better name, that would be able to know what the
applications should be doing, to monitor that activity, and to do whatever
necessary to continue the activity, should anything happen to that activity.
Yeah, non-stop, but not the Tandem design.

Just a concept, and design and implementation might be "interesting".

I'd just note that the OSs would be included as applications, so re-starting
them from where they were interrupted would be included in the concept. So,
yeah, the monitor would be outside/over the OSs. Perhaps something like happens
with VMs. Except VMs want to move the activity to another system, not recover
on the same system.

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

Dave Froble formulated the question :
> On 1/28/2024 8:32 AM, Arne Vajhøj wrote:
>> On 1/28/2024 8:25 AM, Marc Van Dyck wrote:
>>> Simon Clubley formulated the question :
>>>> Does anyone have any others to add to the list ?
>>>
>>> Yes. Some kind of automatic disaster recovery. That is, if a process,
>>> or a set of processes, run on a system that crashes, those processes are
>>> automatically restarted on another cluster member, transparently, with
>>> no manual intervention, and continue from the point they were at when
>>> the system crashed. No transaction lost of any kind, and without having
>>> to add anything in the code that those processes are running. The
>>> operating system (or layered product) does all the work transparently.
>>> Should work with code written 30 years ago, with ACMS applications,
>>> anything.
>>
>> Something like Tandem NonStop lock-step?
>>
>> Arne
>>
>>
>
> Well, no, not really. What I'd envision would be what I'd call an
> application monitor, for lack of a better name, that would be able to know
> what the applications should be doing, to monitor that activity, and to do
> whatever necessary to continue the activity, should anything happen to that
> activity. Yeah, non-stop, but not the Tandem design.
>
> Just a concept, and design and implementation might be "interesting".
>
> I'd just note that the OSs would be included as applications, so re-starting
> them from where they were interrupted would be included in the concept. So,
> yeah, the monitor would be outside/over the OSs. Perhaps something like
> happens with VMs. Except VMs want to move the activity to another system,
> not recover on the same system.

Whatever the design and implementation, this would be a really useful
and marketable addition to the OpenVMS cluster concept. Clusters were
invented 40 years ago to implement horizontal scalability, because
vertical scalability was impossible, technically or financially. This
issue has mostly disappeared today, current hardware being able to
deliver any power we might want. Today's clusters are essentially
put in place for redundancy or disaster recovery purposes ; the next
logical step should be to provide this redundancy in a transparent way
to the system user.

This should also be, as opposed to simple user niceties, something that
allows VSi to make money with.

--
Marc Van Dyck

Simon Clubley wrote on 25/01/2024 :
> On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 1/24/2024 8:13 AM, Simon Clubley wrote:
>>> On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> What is really rude is talking about Linux on c.o.v ...
>>>>
>>>
>>> Unless you consider VMS to be perfect and not in need of any improvement,
>>> other operating systems offer some good ideas that it would be nice to
>>> see in VMS, especially around security and internal isolation in general.
>>>
>>
>> Then discuss the ideas and concepts ...
>>
>
> OK.
>
> A random sample of things from Linux/Unix I would like to see in VMS:
>
> Mandatory Access Controls (my preference) or jails (Stephen's preference).
>
> A shell with decent modern functionality such as:
>
> Proper command history retention and merging from multiple sessions
> Easy searching of command history
> Tab completion
> Editing long command lines
> Globbing
>
> Proper package management and management of updates.
>
> Loadable and unloadable kernel modules, with device driver/filesystem/etc
> functionality available from within these modules.
>
> ASLR and KASLR support.
>
> Proper timezone management. (Everything is always UTC based, and your
> timezone is merely a local session property with no effect on the
> on-disk timestamps).
>
> The last one is policy-based, not technical:
>
> A vendor that has proper security reporting mechanisms.
>
> Does anyone have any others to add to the list ?
>
> Simon.

One of the slogans that were used to sell OpenVMS is "When downtime is
not an option". Yes we still need to reboot the system each time we
install a new operating system or major patch. There should be a way to
perform those operations without shutting down the service. If this is
not possible, rolling upgrades across clusters remain an alternative,
but then we need a way to move a process or a set of processes from one
cluster member to another without any impact or user visibility.

--
Marc Van Dyck