SCLI Review Cargill Grain Lab Jim Bostwick SM:[1,100]SCLIREV.DOC Secure Design Review Page 2 1. Introduction This document summarizes design features of the dial-in security project. It is intended to provide a framework for the design review meeting. 2. Overview Dial in security is implemented via a user-written com- mand line interpreter (CLI), plus minor modifications to RSX-11M/M+. 2.1 Source Language SCLI is implemented in MACRO-11. It is required that scli be active at all times (although not necessarily in memory). Thus compact size is important to reduce impact on existing systems. Also, MACRO-11 is the only common language to all of our systems. 2.2 System components The SCLI program performs all protection and logging func- tions. Modifications to the RSX BYE program allow it to en- able SCLI protection when a protected terminal is logged off. A patch to module TTMOD (modem handling) in the RSX terminal driver allows SCLI to protect remote (dial-in) lines. Event logging is accomplished via two RSX facilities: the console logging task (COT) and the error logging subsys- tem. 3. User Interface The user sees a non-descript prompt, and must enter a valid password. Contents of the prompt are meaningless, and may change from time to time. The password may contain all upper and lower-case printing characters, TAB, and many con- trol characters. Prompt length is limited to 80. characters. Secure Design Review Page 3 The system prints a reply message in response to all input. The reply is generally meaningless in the case of invalid passwords. It will be meaningfull when a valid password has been accepted. The user only gets a few tries (currently 3) to enter a correct password. If three invalid passwords are entered, SCLI enters mumble mode, and the user is required to hang up, wait a predetermined amount of time, and try again. The time delay is currently set at 5 minutes. Having entered a valid password, SCLI greets the user, and resets the terminal to MCR. The user may now log in and use the system. When the terminal is logged out, the BYE task automatically resets the terminal to SCLI control, re- establishing protection. 4. System Interface SCLI functions as an installed task, which is also a CLI. It will be installed using VMR, so that it comes up when the system is booted. SCLI must, however, be started up during STARTUP.CMD. This is a loophole in the system, in that it would be possible to boot the system, bypass startup.cmd, and leave an unprotected terminal. Logging involves a tradeoff between volume of log ma- terial and the desire to record SCLI events. It has been decided to log only login, logout, and 'start mumble' events. This is the minimum log activity which provides a history of port status. It reduces the number of entries during concerted break-in attempts to one every delay period (5 minutes). SCLI also responds to messages. This facility is used to let SCLI know that an attempt is being made to eliminate it as a CLI. SCLI responds to such actions by re- establishing itself, thus making it effectively impossible to break protection by action from another (even priveleged) terminal. Another message tells SCLI to shut itself down. This messgage is a loophole in the security system, and must be protected very carefully. SCLI is inherently immune from being aborted, in that it is started by RSX on receipt of input from a protected terminal. SCLI is immune from being removed, as RSX will not remove a CLI which is 'active', and SCLI protects itself from inactivation. Secure Design Review Page 4 There may be timing windows wherein the proper sequence of MCR commands, issued in rapid succession, may be able to shut SCLI down. This has not been shown to date, however. 5. Maintenance SCLI contains an internal, encrypted, table of pass- words. Each password has a corresponding command record, containing the reply string, pass/fail flags, and a plain- text user-id (for logging). In order to change passwords, it is necessary that module LOOKUP be reassembled with the new password table, and SCLI re-linked. The normal maintenance activity will be to rebuild LOOKUP.OBJ at the Grain Lab, RFX it to the plant system, and rebuild SCLI.TSK on-site. It will also be possible (though difficult) to ZAP SCLI.TSK on-the-fly. Source code for SCLI will remain at the Grain Lab. Plain text for the password table need not be on any system. CONTENTS 1. Introduction . . . . . . . . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Source Language . . . . . . . . . . . . . . . . . 2 2.2 System components . . . . . . . . . . . . . . . . 2 3. User Interface . . . . . . . . . . . . . . . . . . . . 2 4. System Interface . . . . . . . . . . . . . . . . . . . 3 5. Maintenance . . . . . . . . . . . . . . . . . . . . . 4