[nSLUG] linux and large organization security policies

George N. White III gnwiii at gmail.com
Sat Aug 16 13:46:18 ADT 2008

My colleagues and I are finding it increasingly difficult to work under the
evolving security policies of the various governments.  I might also
mention that some colleagues who work at universities find that
rampant worms, viruses, and hacking are a big problem for people
trying to get some work done.

A NASA user of the R stats package reported a bug in a old
version he is using.   Of course he was told to upgrade to the
current version, which prompted the  following:

"PS:  NASA is trying to put institutional barriers to things like
updating R as you suggest, but I will do all I can.  It is important
to speak out against central-point-failure regimes of "computer
software security" in all large organizations.   These put updating
in the hands of those who have no experience with the packages
that scientists use.  "Do it with Excel" would be the reply to request,
or the request would be delayed until it could be billed to my resources.
This condition is all to common, ... sigh."

I know a number of people in the local area who were told to
"Do it with Excel" when they asked IT support for help with R, so
the problem is not just with NASA.

Some common elements of a 2008-vintage generic
corporate/government/research institute security policy:

1.  administrators must have security training/certification

2.  machine rooms are locked, and only admins have physical access

3.  adminstrators are responsible for operating the systems, applying
    vendor patches, etc.

4.  administrators may install "approved" 3rd party applications under the
   following conditions:

   a. 3rd party software must offer functionality not provided by corporate
      standard tools (Excel) and must be tested for compatibilty with
      corporate standards.

   b. 3rd party software must have a support contract with maintenance and
       security updates.

   c.  users must pay the costs of 3rdparty  software and admin overhead

So far, the policies do not prevent users from installing software that does
need root privileges.  In the days of Sun and SGI, scientists were used
to building apps from sources, and arranged things so that they did
not need root access to do it.   Now we have linux distros with
many of the packages available  in binary form.
If the app needs a library/version that isn't installed by default,
you have to arrange to provide it yourself.  This is a lot more
work than "sudo yum install ..".

Item 4a is causing many problems  A widely used statistical test is available
in R and has been extensively tested in practice.  Sure the test could be
done using Excel, but it would certainly be questioned in a peer review
process where the majority of reviewers are familiar with R, know the
limitations and pitfalls, and can easily run the test themselves.

It has always been true that security is better servied by minimizing
the things done by root, so in a way, the policy could work if it
did not mean a return to the days when users had to build everything
from source manually.  Most linux distros require root to install
packages that only use root privileges to update the database of
installed packages.  Ideally, users could install packages and
the admin would be able to add user-installed packages to the
database.  In practice I can image being called onto the carpert:
"We told you to use Excel and you installed R", so maybe it isn't
all that bad if admin remains ignorant.

Many organizations are implementing fee for service models
for which even the most basic service level exceeds historical research
budgets.   There many examples where the admins have installed some
package to point where they can run the GUI, but have never used it for
a real calculation.  I know an example where TeX was installed so that
the user's home directory was on the search path, so every invocation
of a tex program recursively searched the user's home directory,
including nfs mounts.  Since the administrator doens't do any real
data processing, tex would work fine for the admin's account, but
was totally useless for the people who needed it for "real work (tm)".

I think many package managers do support mechanisms to
install in an alternate root, but I haven't needed that until this year.
I would be concerned that the package manager would not
deal with conflicts with packages installed in the usual way.

The one thing that might make it possible for users to regain
some control (e.g., the poor guy at NASA can install a current
R version) is that disk is cheap and data sets are so big that
many users would not have problems installing a few Gbytes
of private packages.

There are a couple systems that provide package management
independent of the underlying distribution: macports (which
is claimed to work on bsd as well as MacOSX) and openpkg.

By default, openpkg uses root to create a new user/group, after
which you can use "sudo -u openpkg".  The documentation
Support for unprivileged user

Unless a package explicitly requires "root" privileges, i.e., a
network daemon listening on an UDP/TCP port below 1024,
an [sic] user can place a private instance of OpenPKG in any
writable location like his home directory

Has anybody actually used this private instance of OpenPKG?
Did you encounter any problems?

One issue is that some environments need server processes.
On the SGI machines at work we have an application that needs
access to an X Server to render fonts when you create images.
Some processes take days to generate the image data, then
need access to an X Server to finish writing the output image.
Users who try to run such jobs using the X Server on their
workstation can't reboot until the job has finished, so it is
much better to use Xvfb running on the same system used
for batch jobs.  Normally, Xvfb would be started by root, but
it is possible to run it without root privileges if you use TCP
instead of sockets for the communications.  There are other
examples of server processes that may be invoked by users:

ssh-agent (with set gid to nobody), dbus-daemon,
license agents for commercial apps (Matlab, etc),
the Eclipse Help System, etc.

The Eclipse Help System is an interesting case.  It uses
a tomcat web server and help pages can be viewed
with the Eclipse built-in viewer or some other browser.
It is a nice system, and some applications have started
using it.  Normally, the web server is started "on demand".
For many sites this seems to work fine, but other sites
find that only root can start the server.

Maybe there is need for a new type of linux distro that
provides separation between a core system and user
applications.   This would need extensions to the LSB,
perhaps adding /usr/<group> trees for applications
shared by <group> and ways to deal with the database
of installed packages where different groups might
use different versions of the same package.

George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia

More information about the nSLUG mailing list