[Info-vax] OpenVMS Security (was: Re: Problem with Filezilla connecting to OpenVMS)

[Stephen Hoffman]

On 2018-12-11 18:40:14 +0000, Dave Froble said:

> Our users require SYSLCK.  On VAX it was simple, for me.  On Alpha it 
> was much harder, for me.  Ok, Dave's a dummy.  It was still much harder 
> for me.

OpenVMS is incredibly clunky, here.  Its handling of this and similar 
cases is woefully dated, and entirely brute-force.

> So, there is a UWSS, installed with privs, on every user system.  Can 
> it be a security issue?  I don't know.  I will admit that just about 
> anything could ultimately be a security issue.
> 
> First point, there are users with privs, and they can, and do, install 
> images with privs.  It happens.

The OpenVMS privilege design is somewhere between problematic and 
archaic.  Maybe VSI gets around to adding app-specific entitlements for 
signed apps, and provisioning-related support, and gets away from 
system-wide entitlements.  But that's several years out, at the 
earliest.  This akin to how OpenVMS resource and subsystem identifiers 
allowed apps to avoid needing heavy privileges, sandboxing and 
entitlements avoid needing privileges and help to isolate the access 
granted for other system-wide activities.  Not a panacea, but does 
increase the difficulty of exploitation.  Sandboxing and entitlements 
and provisioning and distributed app and system management are most of 
the foundation of a viable app container system, too.

Related reading:
https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html#//apple_ref/doc/uid/TP40011183 


What little (and old) OpenVMS app design doc suggests app isolation 
across processes here, too.  None too well, though.  And with some big 
gaps in what's available.  Some other operating systems provide 
mechanisms specifically intended to provide and simplify that 
isolation, too.

Entitlements are akin to OpenVMS identifiers that grant what would 
otherwise be privileged access to specific objects, though these 
entitlements grant access to specific operations and APIs and services, 
and these entitlements can be packaged directly with the apps and 
automatically granted to specific applications at app install and 
without resorting to an INSTALL-like process or end-user interactions 
in site-local startup files.  And the ability to digitally sign the app 
bundles against modifications, something that OpenVMS has long lacked 
outside of the install-time secure-delivery context with PCSI and 
VMSINSTAL.

> Second point, which you just don't seem to get.  One does what one has 
> to do to get the job done.  Without that, YOU DON'T EXIST!  It's just 
> that simple.

We all understand your point here, David.  Apps gotta app, or 
management gets cranky.

Downside of what's currently available on OpenVMS is that overhauling 
existing apps and of writing new apps securely can be somewhere between 
difficult and arcane on OpenVMS, and mistakes here can mean 
app-specific and sometimes system-wide vulnerabilities.

Many existing apps will only get security upgrades after code reviews 
or after breaches.  Which might well be approximately never, too.  Or 
at least not until the credit card and other financial data and 
passwords start showing up on the carding forums.

> So, can there be security issues?  Yes, there can, and most likely are. 
>   We do what we can.  Expect more, if you wish to do so.  Doesn't mean 
> you're being rational.  Doesn't mean you're going to get any 
> satisfaction.

You've just described how various operating systems and applications 
got themselves into trouble, too.  These compromises get accreted.  
That's part of computing, and part of installed bases.   But the 
addition of new paths leading away from the needs for these messes and 
these compromises is important for the mid- and longer-term success of 
the apps and the environment.

OpenVMS just isn't very good at creating secure apps.   What do I mean 
by this?  Well, I *dare* anybody reading here to write a secure OpenVMS 
client-server demo app using TLS, with both the client and the server 
cryptographically verifying the peer against interception, with 
encrypted network connection on, using commercial certs.  No tunnels 
and no VPNs for the client-server, and no IPsec requirements.  TLS 
only.  I *dare* you.  I'll be considerate here and not require the use 
of current TLS support (which doesn't yet exist on OpenVMS), nor will I 
require a secure distribution for the commercial root CA storage, nor 
will I expect you to write this app using Fortran, BASIC or COBOL. Nor 
will I expect you to achieve that with DECnet.  Nor will I require the 
use of the why-is-this-still-around CDSA. And this particular area 
isn't the only part of OpenVMS security and OpenVMS app development 
more generally that's stuck pre-millennial.

VSI advertising would be best closer to security self-effacement, and 
further from the current security self-immolation strategy, pending a 
whole lot of work to make OpenVMS more competitive.

TL;DR: your app needs SYSLCK because OpenVMS doesn't have a way to 
target the specific access without resorting to privileges directly or 
via UWSS or ilk.  The UWSS is often the best available approach for 
these requirements, but it's far from the best approach.


-- 
Pure Personal Opinion | HoffmanLabs LLC