Re: Upcoming time boundary events

In article <1026ke1$hh9a$1@dont-email.me>,
Simon Clubley  <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-06-05, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 05 Jun 2025 10:44:51 +0200, Marc Van Dyck wrote:
>

Lawrence D'Oliveiro laid this down on his screen :

>
Basic security should be built into the core OS installation, not added
as an afterthought -- and an extra-cost one at that.

 
There are already many security features available in OpenVMS. More than
what many people need. There must be a trade-off. Building more stuff
into the OS means that more customers pay for features they don't need.

>
Look at what comes standard in the Linux kernel: cgroups, namespaces,
containers, virtualization, SELinux, AppArmor, the whole pluggable LSM
mechanism, seccomp, netfilter, EBPF ... and that?s just off the top of my
head.
>

>
It also has ASLR, KASLR, shells that don't have access to privileges
outside of the privileges the user has, and encrypted filesystems.
It also has secure password hashing algorithms and a central source
of entropy, both of which have only recently been added to x86-64 VMS
(but not added to the other VMS architectures).
>
On a non-security level, it also has support for filesystems in user
space, and pluggable kernel mode filesystems (which can be unloaded
again without needing a reboot).

It's also huge, includes code of widely varying levels of
quality, and much of what is, at best, described as "dubious"
provenance, the vast majority of which is written in a type-
and memory-unsafe language.  Not that OpenVMS is better in many
of these ways.

Frankly, it's amazing that Linux works as well as it does, and
has as few security vulnerabilities as it does.  But it does not
have what any reasonable person would call a coherent security
architecture.

What is, perhaps, true is that, because Linux is so widely
deployed and available, a lot of people understand (at least at
a gross level) _how_ to configure it to a reasonable level of
security for a given task.  The same is not necessarily true of
other systems.

- Dan C.