[Info-vax] How would you load balance excess webserver traffic between multiple OpenVMS servers?

[ultr...@gmail.com]

On Tuesday, January 12, 2021 at 11:19:01 AM UTC-5, Stephen Hoffman wrote:
> On 2021-01-12 13:52:49 +0000, Simon Clubley said: 
> 
> > If that's what you think security is all about in 2021 Bob, then you 
> > simply don't have a clue about what is involved.
> Bob has an unshakable confidence in the validity of his one answer to 
> any and all computing requirements: OpenVMS. 
> 
> That answer might have been ~feasible ~30 years ago. 
> 
> Tasks and requirements and expectations and competition and pricing and 
> apps are all very different now.
> > BTW, you don't even have to go through security, you can go around it. 
> > That's exactly what I did and all the protections and ACLs would have 
> > made absolutely no difference.
> A local-privilege escalation is a local-privilege escalation. OpenVMS 
> has had a few. I've attached one of the more famous (earlier) examples 
> below. 
> 
> This is where jails / sandboxes and app isolation is expected. OpenVMS 
> doesn't particularly isolate apps, and trying to use ACLs gets... 
> interesting. I've had DECinspect break my configurations, when the 
> lock-down tooling was used. (Back when DECinspect was in more common 
> usage, too.) A fair chunk of work atop SEVMS would be required from VSI 
> to add jails/sandboxes/isolation, particularly with integrity and 
> signing—secure delivery is rather more involved when the apps 
> themselves cannot be trusted to be free of malware and free of flaws. 
> And then there's app auditing and app provisioning and app updates and 
> a variety of other topics. Getting this all configured and going is the 
> smaller part of the work too. Keeping this going and keeping this 
> secure and apps current and isolated and secure is no small investment 
> in time and tooling and focus. 
> 
> There's also little app development guidance available for writing 
> secure apps for OpenVMS, which doesn't help. The security manual omits 
> much that is expected of apps in this networked era.
> > To everyone else: I keep warning you about security researchers 
> > possibly taking a serious interest in probing VMS at some point in the 
> > future and about everything that could come from that. 
> > 
> > If Bob sets up some kind of conservative social networking environment 
> > using VMS (which it is a poor choice for anyway), then that is 
> > _exactly_ what is going to happen.
> Bob and the particular "maybe" project most recently now seems moot, as 
> the "maybe" customer has reportedly acquired different hosting. 
> Ignoring that for the moment, and reviewing some other of Bob's 
> discussions for those that are unfamiliar... 
> 
> Bob has previously recommended replacing Microsoft Windows desktops 
> with OpenVMS, had widely recommended OpenVMS be used within voting 
> machinery, and now as a high-profile and contentious "maybe" hosting 
> project. 
> 
> Could OpenVMS do these tasks? Given far too much budget and far too 
> much time and far too much retraining and a whole lot of work prolly 
> yes, but all that very far from economically and easily, and likely not 
> securely. 
> 
> Desktop: Approximately no desktop apps and no Office compatibility and 
> no two-factor and no modern browser for OpenVMS—that'd all have to be 
> found or built or added. 
> 
> Embedded: Approximately no benefit and a whole lot of cost for embedded 
> usage, and which fundamentally doesn't address the issues and risks 
> involved with any embedded software. 
> 
> Web hosting: Little tooling is available for running a high-profile and 
> contentious website and one with other issues as discussed in that 
> thread as well as an app that is a DDoS and intelligence service 
> target, and one that reportedly has problems with payment gateways and 
> with getting their client apps onto the major app stores. Though Bob 
> has the opportunity to create the necessary prototypes here, using real 
> data from the "maybe" API. 
> 
> VSI has piles of work ahead with the x86-64 port. Little of which 
> includes OpenVMS for desktop and updates to the apps and tooling that 
> everybody* expects to have access to, little includes OpenVMS for 
> embedded—seL4 was previously recommended for a secure host platform for 
> embedded use though that too necessarily requires knowledge of and 
> integration with election auditing (and approximately none of this 
> addresses the issues Bob believes it would), and little includes 
> OpenVMS for high-end web hosting and related services and which 
> typically involves keeping a current Apache and related tooling and 
> prolly nginx or other web server, as well as one or more application 
> servers (Twisted and/or Tornado and/or Zend, etc), as well as Python. 
> And for sites that can be subject rapid scaling, there'll be the need 
> for tooling to keep OpenVMS current across a variable and potentially 
> increasing number of hosts, to quickly deploy patches, for geographic 
> server distribution for robustness and recovery and latency, log 
> collection and analysis and intrusion detection, and that'd have to be 
> locally written and/or acquired and integrated. Little of which 
> includes app isolation, R^X, jails, etc. And that's all before we 
> discuss the carrying costs of having hardware available for high or 
> peak loads. Approximately none of which is in the plans, and all of 
> which already exists on other platforms and products and apps that 
> target these disparate markets. The x86-64 port will have some benefits 
> around using hosting for added capacity and for peak loading, though 
> that necessarily means hosting, and it means you'll have to expect 
> insecure or hostile peers, though it's wise to assume your local 
> networks also have hostile peers connected. 
> 
> Can OpenVMS do this stuff? Sure. Cost-effectively, and with a 
> reasonable deployment timeline? Nope. VSI is working to address some of 
> this, and particularly for existing OpenVMS customers. The folks 
> running "maybe", not so much. 
> 
> 
> Local-privilege escalation: 
> 
> OPERATING SYSTEM: VAX/VMS V2.1 
> PRODUCT: VAX/VMS 
> COMPONENT: LOGINOUT 
> 
> 
> GRPNAM SECURITY HOLE IN LOGIN 
> 
> PROBLEM STATEMENT: 
> 
> The GRPNAM privilege is an evil demon, allowing the user to 
> invoke its secret entrance for all manner of nefarious 
> purposes not originally intended. 
> 
> 
> RESPONSE FROM DEC: 
> 
> The great wizard VMS confronted the demon, raised his great 
> oaken staff carved in ancient runes, and spoke the magic 
> incantation: 
> "$SETPRV IMAGEACTIVATIONENHANCEDPRIVILEGES $CMKRNL!!" 
> There was a blinding flash of light and puff of smoke, and 
> the demon, reduced to harmlessness, scurried off into the 
> distance. 
> 
> Where his secret entrance had been was naught but a little 
> pile of ashes, which the wind slowly drifted into letters 
> spelling the words "FIXED IN V2.3".
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

so basically you are stating that the "OpenVMS is most secure OS on the planet" sales pitch bellowed by DEC and not so much HP marketing
over the years was just an oxymoron?