[Info-vax] Reinventing VMS logical names (Fuchsia & Win NT)

[Jake Hamby (Solid State Jake)]

On Thursday, November 9, 2023 at 12:12:04 PM UTC-8, Stephen Hoffman wrote:
> On 2023-11-07 18:58:17 +0000, Jake Hamby (Solid State Jake) said: 
> 
> > If I were hired to work on the future of OpenVMS, the one non-obvious 
> > direction I'd explore (anticipating what customers aren't yet asking 
> > for) would be to extend logical name tables and VMS's existing concept 
> > of multiple object classes with common security attributes to provide a 
> > secure way for processes to grant capabilities to each other via 
> > special mailbox messages or special LNM entries in a shared table. 
> > 
> > Not only is this similar to how newer systems like Fuchsia, 
> > microkernels, and exokernels work, but you've been able to pass file 
> > descriptors and other security credentials across process boundaries in 
> > UNIX, at least on the BSDs and Linux, using UNIX domain sockets for 
> > some time.
> There's a foundational question or three awaiting: 
> ... compatibility with OpenVMS. Lots and lots of stuff is possible. 
> Rather less of it is possible with upward-compatibility. Once you start 
> to break stuff a little, you might as well create a plan and 
> incrementally break, err, change more. (e.g. VAX architecture to Alpha 
> architecture.) Which quite possibly leaves you with a MICA-like design 
> or the Apple 32- and 64-bit design or a Dragonfly userland kernel, and 
> all that preferably with a path to encourage moving the old apps 
> forward. 
> ... how much of a market is available for this new platform, and what 
> part or multiplier of a billion dollars and a decade do you want to 
> spend to get closer to serving that predicted market. Operating systems 
> are enormous projects, nowadays. 
> 
> There's certainly the potential (horrible as it might be?) aggregation 
> and re-design possible here, among the antediluvian PDP-11 logical name 
> scheme, the OpenVMS updates to that scheme and the misuses of same, of 
> LDAP, DNS and mDNS, property list files, registry files, Plan 9 and its 
> fondness for objects, and I'm not at all sure where these sorta-related 
> features might then evolve when hypothetically aggregated together. 
> This all hopefully obviously ties into fixing the DEC C logical name 
> mess, too. A whole lot of this stuff is really quite reminiscent of 
> LDAP, too. 

Those are great points. All of those implementations have a lot of
overlap. Active Directory is Microsoft's flavor of Kerberos + LDAP,
and I'd really like to find time to get hands-on experience with
setting up a home AD domain using Samba and Linux, and then making my
Windows, Mac, and Linux boxes use that for security (and my VMS VMs).

Sadly, LDAP won't be supported on OpenVMS x86-64 until VSI rewrites
ACME agent in something other than Ada. I'd be happy to see them port
GNAT Ada to x86-64, but that's because I think Ada's a good language,
especially the modern versions (Ada 83 is 40 years old now!). Also,
I'd love to get paid to work on such a porting project, since the
OpenVMS Itanium version of GNAT already exists, so it's a bounded
problem that's well within my wheelhouse.

I've had this belief that VMS would be better if you could pass
capabilities around for a long time because I always wanted to build a
public VMS-based BBS where you could use DCL or a menu system and do
things like play games. The problem I never could find an elegant
solution for is exemplified by NetHack, which by default installs
itself with world-writable directories for high scores, which clearly
isn't ideal. The alternative is to install NetHack with privileges,
which it supports, but that has even scarier security implications.

With UNIX domain sockets or any microkernel that has capability
passing, there could be a high score server with no special privileges
and a slightly-modified game would be able to make a connection and
send results, and the game server should be able to verify the user
making the request, and, ideally, that the request is coming from the
original game binary.

Kerberos credentials might be the best way for a user to authenticate
themselves, especially across the network. That's what it was designed
for, and I don't know of a better solution. And verifying that a
binary hasn't been tampered with, from another process, is a hard
problem, so I don't expect to solve that one. If I could, I'd be a millionaire
from being able to solve cheating in multiplayer games.

Keeping in mind what you said about backwards compatibility and
complexity, what I'm suggesting is that there may be a minimal
addition to the OpenVMS API so that apps could explicitly pass
credentials or rights identifiers or to authenticate the UID of the
requester, like UNIX domain sockets often support. I think that
addition ought to reduce the necessity of using installed images with
privileges and shared sections, which seems to be how people attack
these problems in VMS, to the detriment of system security.

> Dragonfly is a fork of BSD with a whole lot of new work happening 
> within, not the least of which is HAMMER2 (a BSD file system 
> implementation influenced by zfs), and where some of the other work is 
> sort-of following above capabilities-related suggestions: 
> https://lists.dragonflybsd.org/pipermail/commits/2023-October/922780.html 
> (note how many modules the change touched, too.) 
> 
> One hypothetical path forward would involve loading OpenVMS into a 
> subsystem within Dragonfly. Yeah. But that's not happening. Ever. 

I tend to forget about Dragonfly BSD, so it's good to know they're
working on interesting ideas. In a real sense, OpenVMS is running as a
subystem now whenever it's running in a VM. People don't tend to think
of OpenVMS as "lightweight", but since it was originally designed to
run on an extremely resource-constrained system by today's standards,
I don't think it's out of the question to approach security
partitioning by setting up multiple VMS VMs, not clustered, each in
its own security domain.

> Possibly apropos, some related tooling: https://github.com/rpetrich/callander 
> 
> And yeah, Fuchsia is among the more interesting re-thinkings happening 
> past or prescient, save for the understandable concerns about another 
> habit of the Chocolate Factory: https://killedbygoogle.com 

That's something that was always on my mind from the time I heard it
announced. Honestly, I thought Fuchsia would have been killed before
ever shipping on a Google product, but that prediction was very wrong.
Thanks to Dart and Flutter, Fuchsia was able to be competitive with
Android at providing a good-looking GUI.

>From a political standpoint, Google probably wanted to have an escape
hatch from the limitations of both Android and ChromeOS, the first of
which is a victim of its own success in terms of now being locked into
its own specific architecture and way of doing things (focus on a JVM,
"the zygote", needing two different zygotes to run 32-bit and 64-bit
apps). ChromeOS is basically a lightweight kiosk-style Linux distro,
which isn't all that interesting from an innovation standpoint.

> PS: unrelated to the above, lots of fodder for finding latent security 
> bugs that might exist within their OpenVMS implementations continues to 
> become available, too: https://links.hackliberty.org/post/134157 

So many buffer overflow exploits, so little time. If only everything
had been written in Ada 95 (or newer).

Regards,
Jake Hamby