Limited Access Restricting user access through the application
From "VS Workshop",  Access to Wang, June 1992
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

The little discussion of security found in Wang publications is based on the assignment of file classes to data files and corresponding rights to those files to the end users. Since production data files are almost always opened in SHARED mode, the user must have WRITE access to the data files. Sharp users may discover - accidentally or otherwise - that this gives them the power to delete production data files.

In the past, system administrators have reacted to this situation by closing access to the Command Processor (i.e. no access to the HELP key), but this also removes access to the Print Queue and other important HELP functions. Recently, utility vendors have provided programs that remove specified functions from the Command Processor, but this requires the purchase of a tool and a commitment to maintaining user-level access profiles.

Program access to data

An alternative approach to file security is to grant data access through the application programs; that is, give the programs access to the data and the people access to the programs. The VS operating system allows object files (programs) to be assigned access rights just like individuals. Users running these programs temporarily inherit the program's rights to the data, but their actions are restricted to what the program can perform.

This approach offers a number of benefits, including:

• The Command Processor: access to the Command Processor can be retained, since users would not have direct rights to any file and thus would be unable to harm any. End users are still able to view and manage those file created by themselves.

• Minimal maintenance: typically, menu programs can be used to control access rights. This means that there are only a handful of programs with special rights, minimizing the effort required to maintain those rights - provided you already have menu programs capable of controlling individual user access. Contrast this activity with that of maintaining a complex cross-reference of user and file access rights.

• Program logging: menu programs can be set up to log program usage, allowing administrators to monitor sensitive programs such as COPY, DISPLAY, EDITOR, or EZPATCH. In the event of a security violation these logs could be used to locate the responsible user, workstation, date, and time.

There are also a number of potential pitfalls in using program access rights. Program rights are retained by object files only; procedures cannot be assigned rights. The rights can be lost if the file is copied or modified; BACKUP retains program rights. Finally, special rights apply to all sessions within the program; thus, the DISPLAY utility could be used to view the password file (USERLIST) if run from a menu with System Security Administrator rights.

Applying program-level security

Before assigning program access rights, review the file classes of the data files to ensure that all have been protected properly. Since access to programs will control the modification abilities of the user, it is a good time to review the capabilities of the programs and match them to the needs of user groups and individuals within your organization.

Special Access Privileges are normally assigned through the Wang SECURITY utility. From the main menu of SECURITY, enter the file name and location and press PF9. The current rights of the program are displayed; as with user security, enter the privilege level (Execute, Read, or Write) next to the file class. Programs may also be given System Security Administrator status, allowing access to all file classes plus files of any ownership.

To review your work, locate the file through Manage Files and Libraries and display its characteristics. The Special Access Privileges will show in the upper right of the screen in an area normally blank. If System Security Administrator rights have been assigned, the display will show a pound sign (#) in addition to all 26 letter of the alphabet.

After the programs have been assigned rights to the data files, user rights can be restricted to just those classes required to execute the programs. For example, if the program file has a class of A and Special Access Privileges that grant WRITE access to class X, the user must have EXECUTE rights to class A to run the program but will be able to update data files with an X file class even if they have no rights to X themselves.

If you have a large number of programs to be protected, the UPDATFDR subroutine also allows assignment of Special Access Privileges. You must construct bit-level masks for the respective levels (Execute, Read, or Write) - just like those returned from EXTRACT to display user security levels. Calls to UPDATFDR for assignment of Special Access Privileges must be made by a user with System Security Administrator rights or the call will not be successful. For further information on this approach, review documentation on the READFDR, EXTRACT, and UPDATFDR subroutines in the Wang VS VSSUBS Reference (715-0599).

Monitoring programs with special rights

One potential security problem related to Special Access Privileges is the difficulty monitoring programs on the system that have rights assigned. Normally, the only way to see such programs is through individual review within Manage Files and Libraries. These special rights could be easily reviewed by using a little-known utility called CHECKSAP (Check Special Access Privileges), which scanned an entire volume and reported on programs with special rights. Unfortunately, CHECKSAP is no longer available and there is nothing to take its place. To address these needs, I have created a procedure version of CHECKSAP. (See Figure 1, below, for program listing.)

Procedure CHECKSAP extracts file names with the FIND subroutine, verifies that they are program files, and extracts the file's bit masks for Special Access Privileges using READFDR. If the masks show any value other than zero, they are unpacked (using BITUNPK), translated to understandable characters (E, R, or W), and displayed on the screen with the file name and protection class. As shown in the listing, the procedure will search all files on the system; you may restrict the search by modifying the wildÄcard characters used by FIND.

While better than nothing, this procedure language version of CHECKSAP is not practical for general use. Unlike the original program - which used the "VTOC snapshot" method for rapidly compiling file information - the procedure must extract information on each file and it will stop each time a file is found with special rights. Typical run times for the @SYSTEM@ library are in excess of fifteen minutes; obviously, this procedure is intended primarily for educational purposes! Perhaps one of you out there will submit a program version to the USSWU VSAIDS library.

Other security considerations

Whether or not you use Special Access Privileges for access control, you should be aware of some system loopholes that could allow nefarious use of these rights to invade your system. Users with System Security Administrator rights on a foreign system can use programs that have been assigned special rights on your system to view privileged information. Typically, this is accomplished using diskette drives, so you should consider securing such drives from casual use. (By the way, the SECURE = NO option for disk mounting will not restrict programs with SSA rights.)

You must also pay attention to the programs you assign special rights to. Be aware that any program with an option to run a program will inherit the rights of the program running it; unfortunately, the LINK parameter to restrict rights to those originally assigned to the user has no effect. GeneralÄpurpose utilities with view and copy capabilities - such as MANAGER, EDITOR, or DISPLAY - are not good candidates for Special Access Privileges because their functionality extends to data modification. The BACKUP utility should not be available to casual users, since it will preserve program rights even if assigned on another system.

Is program-level security right for your shop?

Program access rights are a secure and practical method of safeguarding data. With some attention to physical security and access to system utilities, Special Access Privileges can provide a more secure environment without unduly restricting user movements.

Figure 1: The CHECKSAP procedure

PROCEDURE CHECKSAP * Checks for programs with Special Access Privileges DECLARE &INFIL STRING (08) INITIAL "? " DECLARE &INLIB STRING (08) INITIAL "? " DECLARE &INVOL STRING (06) INITIAL "? " DECLARE &START INTEGER INITIAL +1 DECLARE &NUMB INTEGER INITIAL +1 DECLARE &COUNT INTEGER DECLARE &RCVR STRING (22) DECLARE &COMPAR, &COMPAR2 STRING (12) DECLARE &FT, &FC STRING (01) DECLARE &ME, &MR, &MW STRING (04) DECLARE &EOUT, &ROUT, &WOUT STRING (32) DECLARE &INLEN INTEGER INITIAL +4 DECLARE &RC INTEGER ASSIGN &COMPAR = &COPY (&BYTE(0),12) MAIN: RUN FIND IN VSSUBS ON SYSTEM USING &INFIL, &INLIB, &INVOL, &START, &NUMB, &RCVR, &COUNT, "A" IF &START > &COUNT RETURN ASSIGN &START = &START + 1 ASSIGN &NUMB = 1 * Extract file information RUN READFDR IN VSSUBS ON SYSTEM USING &RCVR (15,8), &RCVR (7,8), &RCVR (1,6), 0, "FT", &FT, "ME", &ME, "MR", &MR, "MW", &MW, "FC", &FC, &RC IF &FT <> "O" GOTO MAIN [Not a program file] ASSIGN &COMPAR2 = &ME !! &MR !! &MW IF &COMPAR2 = &COMPAR GOTO MAIN [No special rights] * Translate the bits from the extracted fields RUN BITUNPK IN VSSUBS ON SYSTEM USING &ME, &EOUT, &INLEN RUN BITUNPK IN VSSUBS ON SYSTEM USING &MR, &ROUT, &INLEN RUN BITUNPK IN VSSUBS ON SYSTEM USING &MW, &WOUT, &INLEN * Convert the bit masks to characters ASSIGN &EOUT = &TRANSLATE (&EOUT, " E", "01") ASSIGN &ROUT = &TRANSLATE (&ROUT, " R", "01") ASSIGN &WOUT = &TRANSLATE (&WOUT, " W", "01") PROMPT CENTER BRIGHT LINE "Check Special Access Privileges"; ; CENTER "File =", LINE &RCVR (15,8), " in", LINE &RCVR (7,8), " on", LINE &RCVR (1,6);; CENTER "File class =", LINE &FC;; CENTER " ", LINE "*ABCDEFGHIJKLMNOPQRSTUVWXYZ"; CENTER "WRITE protection = ", &WOUT (1,27); CENTER "READ protection = ", &ROUT (1,27); CENTER "EXECUTE protection = ", &EOUT (1,27);; CENTER "Press RETURN to continue"; GOTO MAIN