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

[Stephen Hoffman]

The following message was copied from elsewhere, as it appears the 
original was dropped with the deluge of spam from the tsunami of spam 
from Google accounts.


On 2023-11-07 hh:mm:ss +0000, Jake Hamby (Solid State Jake) said:

> On 2023-11-09 20:11:59 +0000, Stephen Hoffman said:
> 
>>> 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.
>> 
>> 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.
>> 
>> 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
>> 
>> 
>> 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

There are large identity management vendors maneuvering to increase 
their installed bases, not the least of which is Microsoft Windows 
Server Active Directory, more recently Microsoft Azure Active 
Directory, and now Microsoft Entra ID.

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

I was using OpenLDAP from macOS Server for all that for a while. 
Including for OpenVMS. It worked.
The OpenVMS LDAP external authentication integration and implementation 
and documentation was, well, atrocious, but could be gotten to work.
ACME itself has had a bad case of DEC design (not to be confused with 
the former DEC product DECdesign), where it could solve all sorts of 
issues, but the simplest and most common cases were... complex.

> 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 objected to the original use of Ada for ACME. There are stories here, 
but those are best saved for another time and place.

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

Yeah, no. OpenVMS has no concept of sandboxing, and various of the 
OpenVMS concepts of protections and sharing are more or less directly 
from the US DoD / NCSC Rainbow Books, for better and for worse. Great 
for when that arise, but... limited.

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

In an earlier era, that would have been a job for PORTMAPPER. Nowadays, 
it would probably be an mDNS service on the local network.

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

That delegation is going to be gnarly. Closest common older analog is 
Kerberos tickets yes, and that already (mostly) works. But can also be 
gnarly.

Kerberos was never particularly integrated into OpenVMS, along with 
LDAP and other mechanisms, or TLS support, and CDSA came and went.

And Kerberos got caught up in the US weakened-encryption export 
regulations, which did not help availability and adoption.

Newer approach is probably OAuth (maybe with OpenID mixed in), or with 
SAML in some contexts. (Or the identity-management vendors.)

OpenVMS incorporates very little message passing. Job controller and 
some mailboxes and a few other giblets, sure. But it's arguably not 
central to the design.

Semi-related to message-passing: the PID of the sender arriving via 
mailbox can be useful for half-baked home-grown app delegation, but 
that takes work to get it right.


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

So-called system high security replaced multi-level security in most of 
the contexts where the participants had thought they had wanted 
multi-level security. Multiple system high boxes were easier and 
cheaper than fewer multi-level boxes. That was the demise of various 
MLS offerings in the then-current defense and national security IT 
markets. An approach which shrank away back in the late 1980s into the 
early 1990s.

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

Google has some of the best and brightest folks around, working at a 
scale unimaginable to most of us, and too often the corporate attention 
span of a over-caffeinated and click-seeking toddler.

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

Rust would be considered in more recent times. Zig looks interesting 
too, but that's given the huge piles of C code around.


PS: Some brief details on DECdesign, and a whole lot more about 
industrial process control, SCADA, and related from that same era:
http://www.bitsavers.org/pdf/dec/vax/realtime/EK-RPTSS-TM-004_Real-Time_Products_Technical_Summary_Dec92.pdf 



-- 
Pure Personal Opinion | HoffmanLabs LLC