[Esip-preserve] Security and Configuration Management Issues

[Bruce Barkstrom via Esip-preserve]

If you haven't heard from the standard news media,
there is a serious vulnerability in some Linux bash
installations.  You can check on vulnerability using

env X='() { (a)=>\' bash -c "echo date"; cat echo ; rm -f echo

If the output shows the date, your Linux system or systems may
have the vulnerability (CVE-2014-7169).  CERT ranks this as
category 10 (meaning top level for potential damage) and as
easily exploited.

Second, the new CACM has an article [Kern, C., 2014:
Securing the Tangled Web, CACM, 57, No. 9, pp. 38-47]
describing concerns over script injection vulnerabilities
(with emphasis on JSON).  The author is with Google.
He describes the approach Google has taken to deal
with this security concern.  The suggestions he makes
require a lot of discipline and development of a culture
that follows and enforces adherence to certain kinds of
development procedures.

Third, the four popular Linux distributions (Red Hat, SuSE,
Fedora, and Debian) all have separately managed package
distribution procedures.  The first three use RPM, while
Debian (and the Ubuntu derivatives) use .deb.  In these
systems, each package has metadata that includes some
provenance information.  Each package distribution
is centrally managed by the vendor. Red Hat manages releases for its
RPM packages; SuSE manages its RPM packages; Fedora
does the same; Debian manages the .deb packages.
Each chain of packages could be a bit different in the
details of how the package partitions the libraries.

If you only work with one distribution, the centralized
distribution reduces the work you might have to do in
maintaining a particular system.  However, if you have
several Linux vendors or if you're working multi-system
cloud or grid approaches, you could have a lot of pleasantry
with system administration.

I've been working to install Ada on a Ubuntu LTS
14.06 system.  The AdaCore GNAT GPL release (which
is free under GPL for Open Source work) uses a very
different granularity and approach for managing the
configuration.  This approach maintains metadata for
each compilation unit, not each package.  It also has a make-like
capability for dealing with dependencies.  It's an interesting variant
that might be applied to other languages.

I don't think an approach requiring a government-wide
adoption of a single packaging system is workable.
For one thing, these software vendors have customers
outside of government -- and they can lobby.  For reproducibility,
it seems to me that the chain of provenance logic will need
to include the chain of system configurations to be able to
verify which packages a particular collection of data used
in its production.

Bruce B.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-preserve/attachments/20140929/5ef6afa3/attachment.html>