[Info-vax] OpenVMS Security

[Dave Froble]

On 12/11/2018 7:25 PM, Stephen Hoffman wrote:
> 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.
>
>

Well, frankly, I could have used a type of locking that didn't require 
any privs.  Doesn't exist on VMS, and with the DLM available, I wasn't 
going to write another locking system.  Already did that once.  And once 
a cluster is involved, that's a rather complex wheel to re-invent.

Yes, one could argue that nefarious users could mess with database 
locks.  Well, if someone had that much access, they also had database 
access anyway, so what would be the big deal with access to the locking.

But VMS didn't provide any system wide non-prived locking.

And I do understand that the DLM is used for some things that do need to 
be restricted.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486