Security OS Design Issues and Thoughts
Glenn C. Everhart
July 2001
Smyrna, Delaware 19977
(Everhart@GCE.Com)
In spare-time work I have been designing what I think of as an access
control add-in for unix, to be based on the notion of having system
objects (mainly files) tagged with extended access permission flags
which will control usage and are meant to allow efficient detection
and prevention of misuse, and a sensible way to react to mobile or
covert code based on noticing when the code ventures to touch system
objects tagged as sensitive.
This stems from earlier design work for a VMS version, which was
implemented some years ago and forms a starting point for later
design. I want to step back, though, and discuss design principles
under consideration, and offer them for consideration and reaction
by others. Since there is some related work now going on, I hope
that some light can be shed into the best strategy for dealing with
mobile code and access control issues generally. As background I have
been able to use multiple pattern searches, in series, to automatically
locate sensitive data in shared storage. This has used pattern density
as a discriminator and works well enough that I believe that at least
some global, automated classification of sensitive information is
possible. Since the classification is highly business specific I do
not include it in the design plans, save by leaving places to use
its results.
I have observed with interest also the publication of descriptions of
a "SubOS" facility in unix as a way of dealing with the security of
mobile code. I have been dealing with related issues for some time,
having implemented a system on VMS in the mid 1990s which allowed
me to tag files with security tags which could effectively change
the ownership, privilege levels, and running priority of processes
which accessed files.
(Aside for those not familiar with VMS)
It must be realized here that processes in VMS
are far more persistent than they are in Unix, on the whole, that
granting an identifier to a VMS process is a close analogue of
the setuid operation in Unix (it can be akin to a setgid also),
and that VMS has a large number of privileges which govern where
potentially dangerous things are permitted to happen, instead of
an all-powerful root account. These privileges control net access,
many aspects of device access, what functions can be sent to any
device, whether the process may enter any elevated hardware privilege
modes (most commonly exec or kernel), whether file protections
can be bypassed, whether diagnostic functions are permitted, whether
temporary or permanent mailboxes can be created, and many more.
They are not completely orthogonal; someone who has cmkrnl
privilege, for example, may run a program which enters kernel
mode, and from there the program may set other privileges. However,
absent such activity, a program needing kernel mode for some
special device control need not have any elevated privileges with
respect to filesystem access. This has saved many a VMS programmer
from accidentally clobbering filestructures in privileged code.
(end of aside)
While the Safety description below describes what I had in 1995,
there are a number of further developments that I want to incorporate
into followon designs. Even though I have published the entire package
now freely (including sources) on DECUS distributions and given up
on selling it, I am working on a Unix analogue and feel that design
goals for doing OS security effectively are worth discussing. Rather
than re-describe the old work I have let my old description stand.
One will also note that the bundle of functions in the Safety package
is rather thick. This is deliberate. I believe that where useful
functionality can be inserted naturally, the final system will be more
stable with it done in one place than it might be with the functions
separated. In thinking as a systems, not just a security, designer
it is then possible to cover borderline cases which separated
designs cannot cover. Finally, user acceptance of a package requires that
there be something "in it for the user". In the case of Safety, the
existence of a user undelete, and to some extent the storage hierarchy
functions, make it useful to install even if the security specific
functions are to be turned on slowly. Therefore my hope was that
Safety would be a function enabler, and seen as such, rather than
simply another external control on people. From the strict "security"
point of view it doesn't matter. From the more practical point of view
of actually getting the package approved for installation it matters
a lot.
The world has changed since the early 90s though, and my sparetime
unix version work will need to incorporate some additional functions
and considerations. In the hope of stimulating reaction to the
security protection model here, let me list some of them.
* First, and most obvious, the information gathered within a single
machine here must be extended to all of a network, so that protection
based on time of day or on which code is running is meaningful
even across machines.
* Second, the lists of individual accounts for file access need instead
to be lists of roles. The added indirection is a practical necessity
for administration.
* Third, the protections in Safety form a single "tuple" defining
a set of accesses. An object's protection in full generality needs
to be a number of tuples. It may be one only, but must be able to be
more than one.
* Fourth, creation of an object needs to inherit its protections from
its ancestor directory or from its creating process, whichever is
more stringent. I have determined that automated searches for
important data can be successfully carried out via automaation,
so errors in this classification can be overcome. A piece of
covert code which creates new programs, howver, must find that
the new programs also enforce the same limitations. I have had
code to implement this in hand since 1996 (though it is a tad
inefficient; it uses the daemon process for the filesystem to
do the setup from user mode) but did not productize it because
of the low interest in VMS security apps from a homebrew shop.
I now view this inheritance as fairly important. It is simple with
"paranoid mode" to in effect mark a program as suspicious, or to
arrange for the paranoid flag to be set when sensitive data are
accessed. Mobile code has proven inventive, though, at creating
new files and new programs and using facilities for running such
programs which are not directly connected with the creating process
code. Therefore it is essential that where suspicious activity
or origins are noted, that the taint of such origins be propagated
to anything written by a process with that taint. Yes, this is
the good old star property, but without NECESSARILY having the
star property mean absolute prohibition of access. It may only
limit rates of access (see below). There should be a marking
on any file that specifies whether this inheritance should
take place, so that for example known innocuous areas might not
trigger the added checking. (Note that in VMS, the checks are per
device, and different rules per device may be adopted. You may
want to simply disallow writing to the system disk to programs
resident elsewhere, for example. In unix, I would allow checks
to be sensitive to device also.)
* Fifth, access rates must be controllable. Higher rates than
authorized should slow access down or possibly block it; slowing
down is preferred since that is the normal response to covert
channels and prevents a process from crashing which may be only
a little out of spec. The rate of increase of delay is TBD, or
maybe to be set by the site. Add a little constant delay and you
just slow things down. Double the delay with every new read
and you limit total access very effectively.
* Sixth, all checks should have "Warning mode" function so that
it is possible to set the entire system up and have only warnings
when something would be altered, not actual prohibition. This
sort of functional control is for the most part already present in
Safety, though it is considered an "internals" feature and I have
only sketchily published it apart from the source code by this
time. (Publication took place on DECUS SIG tapes, available from
volunteer chain or made available by the DECUS library when each
volume came out. The DECUS SIG tapes come out twice a year, and
have done so since the Spring 1979 issue. The Spring 2001
issue came out in May, 2001 and is available on the Internet at
a few sites.
* Seventh, my existing code to do full softlinks in VMS should be
productized and extended so that various types of conditional
softlinks should be offered. At present one can get Safety to open
one file if access is allowed, another if not. This should be
extended so that certain identity flags can cause softlinks to
be done if they are seen, linking to anywhere else visible to the
system. The identity flags will be potentially inheritable like
other attributes. Various different system check success or failure
will deterministically be able to set identity flag number bits
so that the access check results will determine which of several
possible files may be accessed. There will also be ways to set
such flags in a process (process tree in unix) so that whole
directory trees could appear or disappear depending on what
was running or who was running or what the behavior was of what
was running.
* Eighth, and further out, the facilities here should be extended
so that they get integrated with directory lookup, so that directories
on disk contain not only filename and file location, but content
and security information. Schematically this would use a DBMS
to hold the information, use syntactic sugar in directory paths
to specify SQL type queries a piece at a time, and potentially
replace the normal directory operations altogether. A VMS disk
would have only the [000000] directory and many files in the
index file, but no directory files at all, and a unix disk might
have only / and a lot of files with inodes but no directory entries.
This will be important someday in having the computer help you
automatically find things. One would use site indexing systems
to fill in the DBMS and by default would select files that were
in the current directory (I would keep directory trees) and had
not yet been catagorized.
Thus one might have a file whose path looked like
/foo/bar/$${CONTENT="payroll"}/$${CREALVL=19}/mumble/pays.txt
where the stuff inside $${...} meant queries that would be given
in addition to the query inside the mumble directory to find
a file "pays.txt". Directory listings would do these queries
too, which could mean the file contains the string "payroll" and
was created by someone of pay grade 19 or above. The ability
to interpret the sugar and pass the rest on as normal directory
operations would be in something just ahead of the filesystem and
would allow existing programs that understood file paths to be
used unaltered. Because a newly created file would not in general
have all fields set, it would be left as "not yet tagged" and
included in directory listings by default.
Safety keeps its extra info in its own files, and I would continue
that. It is not necessary and not desirable to have to bend
the on disk format of filestructures to hold the security info.
My measurements indicated a 1% degradation in open speed with Safety
(doing nothing but opens!) even where every file was being examined
for markings without benefit of bitmap. This level of overhead can
be bettered but is not bad. Note too that Safety access failures
are a high signal to noise level indication of intrusion or
misbehavior. I would use this fact to feed data to such engines
rather than attempt to parse audit logs in real time. By
flagging mobile code as in effect becoming someone else, a someone
less trusted than the person at the machine, and making these
markings be inherited by anything untrusted processes create,
we ensure that the default behavior of a program that is not
locally known need not be trusted with much of the system.
(Paranoid mode was initially designed so that you could watch
what areas were normally accessed by a program and block other
accesses. The inheritance of other protections is however a
better scheme. Tagging any program that will access the net
and requiring files to be separately declared not hostile
before they may access anything but minimal scratch areas of
the system gives a system that is much less in need of constant
tweaking.)
* Ninth, I would add direct control over non filesystem objects
to the monitor. While control of privilege mask does this indirectly,
a more direct control would allow access to set mask bits. In VMS
this would mean trapping $assign/$dassgn. In unix it means trapping
the opens to sockets. There would be less finegrain control here,
but at least the open/close type operations would be there to
set up additional access conditions as though the sockets (or channels
in VMS) were files. Disallowing access, faking errors, or allowing
redirection to other channels would be possible extensions.
* Tenth, I would improve the logging of errors in variety and
direction, allowing encrypted logs directly (and not just using
encrypted pseudo-WORM disks; unix might not have these) and allowing
alerts to go to possibly several places rather than one only.
(Only one set of routines needs to be altered to expand this...it is
well encapsulated now.)
All the foregoing are valuable, though the filestructure extension
is the most "blue sky" of the lot. Notice that almost nothing in
Safety cares about file structure detail and nothing in Safety
requires anything of the underlying filesystem beyond the ability
to store its own files somewhere. Because the security information
is vital, there needs to be thought to having redundant copies of
it, and the existing facilities for fixing up inconsistencies
must be extended if these proposals get implemetned.
A unix implementation of this will be structured as a LKM to
get control of some system calls and to provide a communications
path that will not require a full driver, and a wrapper filesystem
which will communicate with the LKM and at least one daemon
process. The reason for this is to allow complex decisions
to be made without need of doing it all in kernel. These
components will allow a call to formulate a message for
the daemon, send it via interaction with the LKM,
place the process in a wait state, and allow it to come out
of the wait when the daemon, via the LKM, terminates the
wait. Note that the daemon's accesses must be untouched, and
selected other processes must be exemptable from control. This
is pretty much the control flow of the VMS version (less the
kernel AST thread for open). It works well and makes few demands
on the particular unix flavor.
The "Safety V1.5" product description gives a thumbnail sketch of
a security package announced publically around 1995 (the date at
which its implementation was complete).
Software
Product
Description
Safety V1.5
Comprehensive Data Safety for your VMS systems.
from General Cybernetic Engineering
Executive Summary:
There are many perils your data faces, and loss of data can cost
time, money, and jobs. Intruders, disgruntled insiders, or
hidden flaws in installed software can destroy records. What is
more, mistaken losses occur constantly.
Safety protects your system and your critical data in three
ways:
1. A comprehensive security system adds extra checks for access
to VMS files so that access by intruders or by people in
non-job-required ways can be regulated or prevented. This allows
your business - critical data to finally be protected against
misuse, tampering, or abuse. Access from programs doing
background dirty work (viruses, Trojans, worms, and the like, or
even programs with security holes which can be exploited
remotely (like Java browsers)) can also be blocked without
damaging normal use. This active protection works three ways: by
checking integrity of your files against tampering, by
preventing of untrusted images from gaining privilege, and by
regulating what other parts of the system an image may access.
2. A deletion protection system provides a way to undelete files
which were deleted by mistake and to optionally copy deleted
files to backup facilities before removal. Unlike all other VMS
"undelete" programs on the market, this facility does not rely
on finding the disk storage that contained the file and
reclaiming it before it is overwritten. Rather, it changes the
semantics of the file system delete to use a "wastebasket"
system and captures the file intact. Thus, this system works
reliably. No others do. This facility is also useful where you
have a requirement to keep all files of a certain set of types,
since the backup function can be used to capture such files
while permitting otherwise normal system function. The shelving
or linking functions are also available for moving copies
offline if this is desired. The Safety protection features are
fully integrated with the DPS subsystem, so that deletion
protection does not involve destroying file security.
3. When space runs out, hasty decisions about what to keep
online often must be made, and the risk of accidentally losing
something important is high. Safety protects you from running
out of space. Space can be monitored and older items in the
wastebasket deleted if it is becoming low, without manual
intervention. In addition, Safety is able to "shelve" files so
that they are stored anywhere else desired on your system, and
they are brought back automatically when accessed. Thus no
manual arrangements need be made for reloading them. Safety can
also keep the files on secondary storage, keeping a "soft link"
to the files at their original site so they will be accessed on
the secondary storage instead. Also, Safety can store files
compressed, or can store them on secondary storage so that read
access is done on the secondary storage, but write access causes
the file to be copied back to its original site. Standard VMS
utilities are used for all file movement, and moved files are
also directly accessible in their swapped sites with standard
VMS utilities. The VMS file system remains completely valid at
all times.
Safety gives you a full complement of tools for dealing with
space issues automatically according to your site policy. These
facilities are safe and easily understood. A comprehensive
utility is provided by which you set your site policy to select
which files are and are not eligible for automatic shelving.
Also you are provided with screen oritented utilities for
selecting files to shelve at any time. Access to the shelved
files of course causes unshelving if the normal shelving-by-copy
mode is used. Also, a simple set of rules permit locating
shelved or softlink target files at any time, even without
Safety running. Safety at no time invalidates your file
structures for normal VMS access...not even for an instant.
In addition Safety contains functions to speed file access and
inhibit disk fragmentation.
The major subsystems of Safety will now be described.
The Security Function System:
Summary:
Managing access to data critical to your business using ACL
facilities in native VMS can be cumbersome and still is
vulnerable to intruders or people acting in excess of their
authority.
Want to be sure your critical records can't be accessed save at
authorized places, times, and with the programs that are
supposed to access them (instead of, say, COPY.EXE)?
Want to have protection against privileged users bypasssing
access controls?
Want to be able to password protect individual files?
Want to be able to invisibly hide selected files from
unauthorized intruders?
Have you read that attacks on machines can happen because a Java
browser points at a web site that damages the system (as has
been reported in the press)? Want to be able to protect your
systems?
The Safety security subsystem builds in facilities permitting
all of these, and is not vulnerable to intruders who disable the
AUDIT facility as all other commercial packages which purport to
monitor access are.
Description: When your business depends on critical files, or
when you are obliged by law or contract to maintain
confidentiality of data on your system, in most cases the
options provided by VMS for securing this data can be cumbersome
and far too coarse-grained.
The problem is that certain kinds of access to data are often
needed by people in a shop, but other access should be prevented
and audited. Moreover, the wide system access that can come as a
result of having system privileges often does not mean that it
should be used to browse or disclose data stored on the system.
A system manager will in general not, for example, have any
valid reason to browse the customer contact file, the payroll
database, or a contract negotiation file, save in a few cases
where these files need to be repaired or reloaded from backups.
Likewise, a payroll clerk may need read and write access to the
payroll file, but not in general with the COPY utility, nor from
a modem, nor in most cases at 4AM. Finally, a person who must
have privileges to design a driver and test it should ordinarily
not have the run of the file system as well.
Given examples like these, it is easy to see that simple
authorization of user access to files is inadequate. While it is
possible to build systems that grant identifiers to attempt some
extra control, these can be circumvented by privilege, and
create very long ACLs which become impossible to administer over
a long period as users come and go.
What is needed is a mechanism that is secure, cannot be
circumvented by turning on privileges, and which provides a
simple to administer and fine grained control that lets you
specify who can get at your critical files, with what images,
when, from where, and with what privileges. It is also desirable
to be able to control what privileges the images ever see, and
to be able to check critical command files or images for
tampering before use, so that they cannot be used as back doors
to your system. It should be possible to demand extra
authentication for particular files as well, and to prevent a
malicious user from even seeing a particularly critical file
unless he can be permitted access.
The Safety security subsystem is a VMS add-in security package
which provides abilities to control security problems due to
intruders, to damage or loss by system "insiders" (users
exceeding their authority), and to covert code (worms and
viruses). It provides a much easier management interface to
handle security permissions than bare VMS and provides
facilities permitting control over even privileged file
accesses, for cases where there are privileged users whose
access should be limited. Unlike systems which only intercept
the AUDIT output, EACF can and does protect against ANY file
accesses, and can protect files against deletion by unauthorized
people or programs in real time as well as against access.
The Safety security subsystem offers the following capabilities:
* Files can be password protected individually. If a file open
or delete is attempted for such a file and no password has been
entered, the open or delete fails.
* Access can be controlled by time of day. Added protections can
be in place only some of the time, access can be denied some
times of day, write accesses can be denied at certain times, or
various other modalities of access can be allowed.
* You can control who may access a file, where they may be (or
may not be), with what images they may or may not access the
file, and with what privileges the file may be accessed. Thus,
for instance, it is trivial to allow a clerk access to the
payroll file with the payroll programs, but not with COPY or
BACKUP, not on dialup lines, and not if they have unexpected
privileges. The privilege checks can be helpful where there are
consultants working on a system who should be denied access to
sensitive corporate information but who need privileges to
develop programs, or in similar circumstances. You specify what
privileges are permitted for opening the file, and a process
with excess privileges is prevented from access. Vital business
data access should not always be implied by someone having
privilege. With this system you can be sure your proprietary
plans or data stay in house, and are available only to those
with business reasons to need them, not to everyone needing
system privileges for unrelated reasons. Unlike packages using
the VMS Audit facility's output (which can be silently turned
off by public domain code) Safety cannot be circumvented by
well known means. Its controls are designed to leave evidence of
what was done with them as well.
* You can specify that images able to run portable code (applet
viewing programs or programs with powerful scripting languages)
trigger a "paranoid mode" system. When this is triggered
(normally when the "loading" image is active), all file opens
by the process running the triggering image are filtered by a
script. This script can be different for different programs,
and is site customized. The furnished sample script will
broadcast the identity of user and of files being opened. It is
trivial to arrange to limit this to unusual files or filesystem
areas. The script can also veto the open. Thus the recommended
way to treat web browsers is to limit their file access so they
may read system areas and a scratch area, and may write only a
scratch area. (The script is informed whether the open is for
read or for write.) This "low-integrity-image" mode in which
all file opens are checked with a site script which can report
or veto access. This can be used to track or regulate what a
Java applet can do, in case someone happens to browse a web
site which exploits a Java hole to browse your system or damage
it.
* You can hide files from unauthorized access. If someone not
authorized to access a file tries to open it, they can be set to
open instead some other file anywhere on the system. Meanwhile,
Safety generates alarms and can execute site specific commands
to react to the illegal access before it can happen. This can be
helpful in gathering evidence of what a saboteur is up to
without exposing real sensitive files to danger. Normal access
goes through transparently.
* You can arrange that opening a file grants identifiers to the
process that opens it and that closing it revokes these
identifiers. Set an interpretive file to do this and set it to
be openable only by the interpreter and you have a protected
subsystem capability that works for 4GLs which are interpretive.
(Safety identifier granting, privilege modification, and base
priority alteration is protected by a cryptographic
authenticator preventing forging or duplication.) This can be
done whenever you want the opening of a file (including a directory)
to cause the process to assume another identity. This is
governed entirely by the program's behavior, so that if your
sensitive directories, for example, are tagged to grant an
identifier "twit" to the process, any files whose ACLs deny
or restrict access to "twit" will prevent access. These
identifiers can be any legal VMS identifiers and are not
restricted in form. Of course, Safety can directly control where
an image may go if targets are controlled by it, but those
who prefer to restrict access by ACL, or who may want to control
access to network devices or the like, can use this facility.
The process does not wholly "morph" into another identity, but
its security relevant attributes can and do change.
* You can actively prevent covert code ( viruses and worms) from
running in two ways. First, Safety can attach a cryptographic
checksum to a file such that the file will not open if it has
been tampered with. Second, Safety can attach a privilege mask
to a file which will replace all privilege masks for the process
that opens it. By setting such a mask to minimal privileges, you
can ensure that an untrusted image will never see a very
privileged environment, and thus will be unable to perform
privilege-based intrusions into your system even if run from a
privileged user's account. This facility is useful to ensure
that processes whose security attributes are being edited
due to their behavior cannot undo the changes. The reason
that privileges are replaced, rather than being only reduced
is that it is possible to use Safety to nominate some image
with carefully controlled access characteristics to do some
privileged activities. This facility will allow such functions
to be done even by interpretive processes provided the
system security officer has set Safety up to permit it. It
is strongly recommended that this facility be used only to
lower privilege levels in normal use. It is far from simple
to write code that will correctly use privilege in an otherwise
less trusted environment.
* You can control base priority by image. Thus, a particularly
CPU intensive image can be made to run at lower than normal base
priority even if it is run interactively.
* You can run a site-chosen script to further refine selection
criteria. (Some facilities for doing additional checking while
an image runs exist also.)
Safety allows you to exempt certain images (e.g., disk
defragmenters) from access checks, and it is possible to put a
process into a temporary override mode also (leaving a record
this was done) where this is needed. Safety facilities are
controllable per disk, and impose generally negligible overhead.
Safety will work with any VMS file structure using the normal
driver interfaces. Also, Safety marking information resides
sufficiently in kernel space that it cannot be removed from
lower access modes, yet it uses a limited amount of memory
regardless of volume size.
Best of all, the Safety protection is provided within the file
system and does not depend on the audit facility. Thus it
prevents file access or loss before it happens, and does not
have to react to it afterwards. Safety allows all of its
security provisions to be managed together in a simple
screen-oriented display in which files, or groups of files, can
be tagged with the desired security profiles or edited as
desired. Safety protections are in addition to normal VMS file
protections, which are left completely intact. Therefore, no
existing security is broken or even altered. Safety simply adds
additional checking which finally provides a usable machine
encoding of "need to know" for the files where it matters.
The Safety Deletion Protection Subsystem.
Description: The Safety Deletion Protection System is designed
to provide protection against accidental deletion of file types
chosen by the site, and to allow files to be routed by the
system to backup media before they are finally removed from the
system. This is accomplished by an add-in to the VMS file system
so that security holes are not introduced by the system's
action.
The user interface is an UNDELETE command which permits one or
more files to be restored to their original locations provided
it is issued within the site-chosen time window after the
undesired deletion took place. In addition, an EXPUNGE command
is provided which allows files to be deleted at once,
irretrievably, where space for such is required. Provision for
automatic safe-storing of files prior to final deletion is
present also in Safety DPS.
Safety DPS is implemented as a VMS file system add-in which
functions by intercepting the DELETE operation and allowing the
file to be deleted to be copied or renamed to a "wastebasket"
holding area pending final action, and to be disposed of by a
disposal agent. The supplied agent will allow a site script to
save the files if this is desired, and then finally deletes any
files which have been deleted more than some number N seconds
ago. If the UNDELETE command is given, the file(s) undeleted are
replaced in their original sites. The supplied system can also
be configured to rename files to a wastebasket area or to copy
them directly, for undeletion by systems people only. (These
options are faster than the site command file option.)
Safety DPS can be configured to omit certain file types from
deletion protection (for example, *.LIS* or *.MAP* could be
omitted), to include only certain files in the protected sets,
or both. This can reduce the overhead of saving files which are
likely to be easily recreated, or tailor the system for such
actions as saving all mail files (by selecting *.MAI for
inclusion).
In addition, Safety DPS monitors free space on disks, and when a
file create or extend would cause space exhaustion, Safety DPS
runs a site script. By setting this script to perform final
deletions, Safety DPS can be run in a purely automatic mode in
which deleted files are saved as long as possible, but never
less than some minimum period (e.g., 5 or 10 minutes).
Safety DPS files can be stored in any location accessible to
VMS. If they are renamed, they must reside on the same disk they
came from. Otherwise they can be stored in any desired place.
Safety DPS is installed and configured using a screen oriented
configuration utility to set it up, and basically runs
unattended once installed.
The Safety Storage Migration Subsystem
Description:
Safety has the ability to move files to secondary storage and
automatically retrieve them when they are accessed. This backing
can be similar to what HSM systems call "shelving", though it
can be done in multiple levels, or it can be done in a way which
permits files moved to secondary storage to be accessed there as
though the files remained online. This resembles what are called
"soft links" in Unix systems, in that file opens are
transparently redirected to a file stored somewhere else
reachable on the system, and the channel reset to the original
device on close. A "readonly link" mode acts like a soft link
for readonly access, and like an unshelve operation where a file
is opened read/write, should this be desired. Full control over
this shelving and unshelving is provided.
This provides a great deal of flexibility in reclaiming space
when the Safety space monitoring function detects that space is
needed. Not only can previously deleted files be finally moved
to backup destinations and deleted, but the system can migrate
seldom accessed files to nearline storage transparently. The
site policy can drive this, or utilities provided can be used
instead.
Where it is chosen to run Safety in a lights-out fashion (with
Safety reacting to low disk situations by emptying older deleted
files from the wastebasket and/or file migration to backing
store), the policy chosen for controlling such setting is
handled by a full-screen, easily used, tool which sets the
policy. Should still greater flexibility be needed, the scripts
used for a number of operations are supplied together with a
full description of the command line interface of the underlying
software. This facilitates linking Safety file management
functions with other packages should such be desired.
Safety can be run in a mode where there is essentially no
overhead at all imposed (just a few instructions added along
some paths and no disk access) for any files except those which
need softlinks or possible unshelving. There is no limit to how
many files may be so marked on a disk. A fullscreen setup script
allows one to select the Safety run modes. Even if Safety is
forced to examine all files for its markings, the overhead
imposes no added disk access and costs only a tiny added time
(typically a percent or two) in open intensive applications. In
addition, Safety can be turned off or back on at any convenient
point should this be desired. (This must be done using special
tools provided for use by those specially authorized to do so.)
Support:
Safety runs on VAX VMS 5.5 or greater or AXP VMS 6.1 or greater.
The same facilities exist across all systems. HSM must be
installed on each cluster node of a VMScluster where it is to be
used but imposes no restrictions on types of disk it works for.
Safety will work with any file structure used by VMS, so long as
a disk class device is used to hold it. It is specifically NOT
limited to use with ODS-2 disks.
The enclosed version of Safety is freely available but comes
with no support. Support can be arranged by contacting the
address below. There is a more advanced version whose soft
links are more complete and which has a few other advantages
over this one; contact GCE also if you are interested in this.
Safety is brought to you by
General Cybernetic Engineering
Glenn C. Everhart
156 Clark Farm Road
Smyrna, Delaware 19977
302 659 0460 voice
302 659 5870 fax
For orders, contact the above address or Sales@GCE.COM.
For technical information contact Info@GCE.Com
For support contact Support@GCE.Com
Note on testing:
This version of Safety has been tested for basic function under VMS
7.2-1 and found workable. Odd corners of functionality should be
tried before attempting to rely on them. Safety will not set identity
related things (identifiers, privs etc.) in multiple personna programs,
but only affects the "natural" personna. It is suggested that such
programs be set up as exempt from Safety checks if their internal
checks are adequate.
Glenn Everhart (October 2000)