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

[Stephen Hoffman]

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