[Info-vax] New VSI Roadmap (yipee!)

[Stephen Hoffman]

On 2015-03-01 02:06:32 +0000, Kerry Main said:

> Imho, it should be possible to release a well architected & well-tested 
> 
> commodity OS product in the future (ok, OpenVMS) which does not 
> 
> require many monthly security patches.

Outside of devops, security beyond that required by regulation is 
seldom interesting.   Worse, if security gets in the way, it gets 
bypassed or disabled.   seL4 and selinux aside, and the occasional 
marketing of some security features to the more technical folks, 
security is not typically a central feature in a product sale.   For 
many folks, if it's got AV, it's good enough.  Even if the AV provides 
the equivalent security of waving a rubber chicken over the box, using 
the specific counter-clockwise waving procedure described in appendix A.

>From what I've seen of it, security is third or fourth or fifth or 
lower on the usual pick list for a volume platform, after data and 
application compatibility, and affordability, and familiarity, and 
ease-of-use, and (yes) perception.

> Can you imagine bringing your Toyota or Ford car in every month to have 
> fixes applied so you can use this product safely?

If I paid little or nothing for the car as compared with the resources 
that went into building and shipping it, yes.  I'd expect ads, and 
specific Toyota fuel and Ford fuel requirements, and that I'd need to 
purchase my travel mugs from sketchy street booths or from the 
manufacturer, and that driving at highway speeds might require an 
in-dash purchase, too.

> As mentioned in an earlier reply, this might include contracting state
> 
> of the art security hackers / companies under NDA to review / hack 
> 
> code before it is released or similar strategy.

There are folks that provide that service.   The best of the folks are 
actually skilled attackers, and have all techniques available to them.  
Most are running standard tools, and usually aren't seeding the parking 
lot with target-logo USB drives with enticing software containing 
customized malware.   As mentioned upstream, defenders have to cover 
everything.  More than a few places lack the budget for an effective 
defense, beyond applying patches.   Attackers need but one 
vulnerability, whether that hole is old or new.  Some of the attackers 
have budgets massively beyond any of the defenders.

> I just do not believe the current model of patch-n-pray is sustainable.

It's unpleasant, but is entirely sustainable, until there is a better 
alternative that still gets the job done.  Even a better alternative 
still involves patches.  Ignoring that VMS lacks the necessary APIs and 
the applications and the compatibility and the distributed management 
tools and the deployment tools and the x86-64 support and the 
compatibility with the existing staff expectations, VMS has already 
been in the patch-of-the-month club for anybody using OpenSSL, so 
you're right back into the quagmire.   Worse, Apache SSL from the SWS 
V2.2 update 2 kit is 0.9.8w from 23-Apr-2012, and that's rather far 
back.  Again, I see no solution here.

> I also do not accept that as a platform gets more popular it automatically
> 
> means more security issues magically appear. This is the banks vs. corner
> 
> stores analogy.

We'll disagree there, then — more complex configurations and more 
pieces and parts means more vulnerabilities, and — even with a good 
team — scheduling and market pressures and increasingly complex 
software can and variously does lead to bugs, too.  Maybe not all that 
many bugs in the classic VMS kernel, but there's a whole lot of 
open-source code around, a whole lot of add-on (privileged) code, and 
there'll be more of it all on VMS in time, should VMS become 
ubiquitous.    VMS was built for an environment were everything 
installed was considered trusted.  The mechanisms for VMS signed kits 
are the first break from that trust, and there'll need to be much more 
suspicion about what's installed and running in the future.

This effort also likely means adding UAC / Gatekeeper defenses, and 
jails or sandboxes or Qubes capabilities to keep the applications 
relatively contained, and ASLR and canaries, and developer-signed 
application distributions, potentially an application store, and better 
patch notification and secure and encrypted patch distribution and 
easier installation mechanisms, and configurable firewalls, and 
distributed event logging, and encrypted cluster transports and the 
retirement of DECnet and telnet and ftp, and encrypted SNMPv3 
management, and authenticated network connections, faster mechanisms 
for porting updates to OpenSSL and Apache and core open-source tools, 
updates to compilers that flag (for instance) strlen() and strcpy() and 
strcat() and such, and central and per-user certificate storage, and 
other security-related features, and whatever other useful 
defensive-security ideas arise in the next five or ten years while VSI 
is beavering away on the port and on these and more likely on other and 
more-directly-revenue-producing projects.  Even with a good development 
team, some of these security upgrades will be found to have 
security-relevant bugs, too.

TL;DR: Give me a viable alternative to the patch-of-the-month club, and I'm in.



-- 
Pure Personal Opinion | HoffmanLabs LLC