Post by Simon ClubleyIf 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.
Post by Simon ClubleyBTW, 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.
Post by Simon ClubleyTo 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