Configuration Management Utilities
Using DEC/VAX ACL's

The programs included here demonstrate the control and utilization
that the DEC/VAX Access Control Lists (ACL) can provide. For those
unfamiliar with DEC/VAX ACL's, they are the extended security
protection mechanisms that provide capability to grant or deny any
resource to any individual or group of individuals. This can be an
extremely powerful way of creating a secure system.

In a normal unclassified setup, when creating a file, by default it
would have the normal protection scheme consisting of the normal
READ, WRITE, EXECUTE, DELETE for the SYSTEM, OWNER, GROUP, WORLD
categories (unless the administrator set the system otherwise).
This file might appear as such:


$> directory/security login.com


LOGIN.COM;84 5 4-JAN-1991 08:06:46.98 [MYGROUP,MYUSERID] (RWED,RWED,RE,)



In a secured system using ACL's an entry may appear as:

$> directory/security LIB:group.com


GROUP.COM;84 5 4-JAN-1991 08:06:46.98 LIB_ALL_ID (RWED,RWED,RE,)
(IDENTIFIER=[MYGROUP,MYUSERID],OPTIONS=NOPROPAGATE,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=LIB_ALL_ID,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
(IDENTIFIER=LIB_RE_ID,ACCESS=READ+EXECUTE)

These ACL entries supersede any and all of the normal protection
attributes. In the case of the GROUP.COM file, it was created in
a directory that had the ACL feature enabled such that all files
placed in that directory assume the ownership of the identifier
LIB_ALL_ID not the person who placed it there. The creator still
has the READ, WRITE, EXECUTE, DELETE privileges but also the right
to CONTROL the ACL entries. The owner LIB_ALL_ID is an identifier
that the system administrator can place on any resource and
subsequently grant to any user or group of users. In this specific
example, anyone that holds the LIB_ALL_ID identifier can do as they
please with this file but the people that hold the identifier
LIB_RE_ID can only READ or EXECUTE this file.

If these identifiers are placed on an application directory and its
contents, the ACL becomes a mechanism for controlling access to
those systems. In this way an administrator can control exactly
who has use or control of a software system.
The down side of using ACL's is that time and effort must be spent
by the administrator to institute and maintain access permissions.
The authorize application and the sysuaf file are the only means of
determining the distribution of the identifiers. Unfortunately
these can only be used by the administrator. The database
administrators and software system developers may need to track and
request access for new users. In order for them to access this
privileged information it is necessary to call upon the VMS "System
Services" to acquire this information. The following example
applications can be run by any non-privileged user and therefor
should be protected (possibly by ACL) from usage by any non-trusted
personnel.


heldby.c This is an application that will look up and
list all identifiers held by a given user.


whohas.c This is an application what will look up and
list the users that currently hold a given
identifier.


The next set of utilities are designed to allow the sylogin.com
command file to automatically set up the users environment
dependant on the identifiers that the user holds at the time of
login. The purpose of these routines is to allow the system and
menus to configure themselves rather than trying to create and
manage many portions of logic and unique menus for each user or
group of users. (One sysop I know was pulling his hair out each
time a new user was added or personnel duties changed he had to
create yet another permutation of sylogin logic and user menus.
Now he just uses the authorize command to grant or revoke an
identifier) If the user holds an identifier for a software system
then the system can configure itself to include the logicals,
symbols, and execute any other code required for that software
system without other users even knowing that the system exists on
the machine. This will prevent users from listing the logical and
symbol tables and targeting the potential systems for infiltration.

button_set.c This routine will allow the sylogin.com to
query the users identifiers, and for each one
found it will create a VMS symbol for a menu
option to be displayed and one for executing
the application (see acl_menu.com for an example).
This routine would most likely be used from a
captive account providing a user menu.

config_set.c This routine will allow the sylogin.com to
query the users identifiers, create a command
file containing any routines to execute. The
sylogin.com can then call the command file to
set up any applications required for that user
and delete the command file when done.

The following depicts the usage of the automatic login
configuration program "config_set.c". When placed in the
sylogin.com file it will automatically call all the DCL command
files for each project that the user has been granted the
identifier for. A user_config.com file is written to the users
sys$scratch: and then executed. After the '.EXE' image has executed
the copies are purged to save space. The DCL sylogin.com procedure
would appear as:

$! This would be included as part of the sylogin.com procedure
$!
$! ** Setting up all logicals and symbols for this user **
$!
$! The parameters are read from SYS$INPUT as:
$! vax_identifier Command_to_execute
$!
$ CONFIG_SET
DATABASE1_RE @[setup]setup_database1.com
APP2_DBA @[setup]app2_group.com
APP2_RE @[setup]app2_group.com
$!
$!
$! Execute the DCL setup file.
$ @sys$scratch:user_config
$!
$! Purge or delete the command file.
$ purge sys$scratch:user_config.com
$!