.NONUMBER .LM 0 ^PY^- .PAGE SIZE 58,85 .LM 10 .RM 75 .NO FILL .NO JUSTIFY # .SKIP 5 .CENTER The RSX Multi-Tasker .CENTER June, 1987 .SKIP .CENTER ##^IS144^G"We've Never Been Proud"^IS204^G .SKIP .CENTER Fine Realtime Commentary Since 1975 .SKIP 6 .CENTER ^&Table of Contents\& .SKIP 2 .TAB STOPS 65 Food for Thought RSX-1 The Editor's Corner RSX-1 New Tricks RSX-2 Submitting Articles to the Multi-Tasker RSX-3 And That's The Way Things Are RSX-3 It's In the Code RSX-4 RSX-11M-Plus Data Cache Manager Change RSX-7 Removing FMS from Indirect RSX-9 Response to February "Bag of Tricks" RSX-10 Security of the RSX-11 Operating Systems RSX-12 The Notebooks of Justin L. Hewser RSX-20 .JUSTIFY .FILL .SKIP 15 .LM +5 .RM -5 Opinions expressed in the editorial section of the Multi-Tasker are those of the Editor. They do not represent the official position of the RSX SIG or that of DECUS leadership in general. .LM -7 .RM +7 .PAGE .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Food for Thought .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT # .SKIP 7 .AUTOPARAGRAPH .CENTER ^&Food for Thought\& .SKIP "Pitiless indeed are the processes of Time and Creative Thought and Logic; they respect the convenience of none nor the love of things held sacred; agony attends their course. Yet their work is the increasing glory of a world - the production of psychic light - the growth of knowledge - the advancement of understanding - the enlargement of human life - the emancipation of Man." .SKIP 2 .INDENT 30 ^IS144^G- Cassius J. Keyser^IS204^G .INDENT 30 ^IS144^G##Mathematical Philosophy^IS204^G .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT The Editor's Corner .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .SKIP 9 .CENTER ^&The Editor's Corner\& .SKIP .CENTER Bruce R. Mitchell .SKIP As we go to press, the Spring Symposium is only two days away. For obvious reasons, we don't have any reports from the Symposium in this issue. But hang in there, they're coming. We have a pretty fair selection of articles this month. Something that we've all wanted to see for a long time is here - an analysis of weak points in the RSX security system. Read it. Apply it. If you don't - don't bitch about your system being penetrated. Jim Preciado returns with "It's In the Code" this month, to discuss some seldom-seen but very useful options in the M-Plus Executive code. There is a patch to the M-Plus Data Cache Manager. From Gary Maxwell comes an article on removing the seldom used and mostly useless FMS code from Indirect. And Justin L. Hewser, infamous RSX system programmer and man about town, shows up again with another of his gems of wisdom in "The Notebooks of Justin L. Hewser". The Editor is pretty tired this month, what with prepping for the Spring Symposium. The Editorial is short. But you, the users, asked for this one specifically. So here it comes. .SKIP 2 .CENTER ----- New Tricks ----- .SKIP The RSX SIG has been around for a long time. It is one of the oldest SIGs, if not the oldest SIG, within DECUS. Next year the SIG celebrates its 15th anniversary. A few years back (Multi-Tasker article: "Whither Goest the SIG?") I said that ten years is a long time for a computer architecture to endure, much less an operating system. Well, we're looking at our fifteenth anniversary next year. DEC's competitors have never done as well, despite all their "hot, fast, new industry standard hardware to be announced sometime next year". Each year at the "Woods" meetings the SIG leadership examines the directions for the SIG's future. Those directions have become somewhat circumscribed recently, but there's still a lot of room for us. "Small" (by VMS standards) multitasking systems are still needed in many applications. Certainly we are not ready - as some have suggested - to amalgamate all PDP-11 users into a "16-bit SIG". Remember what happened to the 12-bit SIG? "What 12-bit SIG?" you ask? Right. Users ask me: "Where is RSX going?"## I can only answer: "Where are you going?"## Usually the response to that is - "To VMS." VAXes and VMS are not the answer to all problems, contrary to what DEC keeps trying to cram down our throats. They never were and still are not a real-time answer. Look at the size of the VMS Executive. It still takes time to execute code, and more code takes more time to execute. This is one of the reasons that RSX is faster than VMS for real-time applications. Even so, it would be a canard to state that RSX is still the universal solution. There was a time when this was true. It is no longer so. But RSX systems still front-end the plant VAX clusters and control the machinery out on the floor. Why? Because they're good at it. They're inexpensive. A lot of proven and available software exists. If Digital would wake up and decide to sell PDP-11s as a commodity, not as systems, they would kick 68000s right out of the real-time control market. Can a $3,000 11/73 be built and sold? Yes. It would be the death knell for VMEbus systems. Will Digital do it? Probably not. Why not? Because there's no market for it. Why is there no market for it? Because Digital isn't making, selling and pushing such a machine. "Does RSX have a future?", you ask me ... RSX has a future. How long a future, and what kind of a future, is not apparent yet. Ask me in another 10 years, when V8.0 of M-Plus comes out. Where is RSX going? That depends on DEC and on us. As long as we keep buying PDP-11s, RSX has a future. .TEST PAGE 5 .SKIP 2 .CENTER ----- Submitting Articles to the Multi-Tasker ----- Please submit machine readable media if you can. RX01, RX02, RX50, or 9 channel magtape at 800 or 1600 BPI are best. Any RSX volume format is acceptable except ROLLIN or PRESRV. ANSI, BRU and DOS FLX formats are well-liked by the Editor's tape drive. The Editor can now Kermit articles into the Multi-Tasker host. The reverse is unfortunately not true; the Multi-Tasker host is normally an isolate. If you want to submit via Kermit, call beforehand with (1) phone number, (2) login for the host machine and (3) system uptimes. Submissions which aren't machine readable take longer to get into print. The editor is lazy and types mass quantities only once a month when progress reports are due. If you preformat a submission in RUNOFF, please set page size 58,80; left margin 10; right margin 75; and, when changing margins, use incremental changes rather than absolute. The editor blesses you for the consideration. Send all submissions to: .SKIP .NO FILL .NO JUSTIFY Bruce R. Mitchell Machine Intelligence and Industrial Magic PO Box 816 Byron, MN 55920 (507)#775-6268 .JUSTIFY .FILL .TEST PAGE 5 .SKIP 2 .CENTER ----- And That's The Way Things Are ----- _... this month in Pool Lowbegone, where opposition to VAX/Elan is strong, real switch register front panels are good-looking, and the number of systems that come in on time and under budget is above average. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT It's In the Code .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&It's In the Code\& .SKIP .CENTER James J. Preciado .CENTER Crossfield - Composition Systems, Inc. .SKIP 2 .CENTER Some RSX-11M-Plus Executive Debugging Hooks .SKIP Even Digital must debug code. Astonishing thought, but true. Sometimes they even make it easy on us users. Recently I discovered some hooks in the RSX-11M-Plus Executive that are extremely useful to device driver writers and other developers of privileged code. One of these hooks allows for the the detection of double forks by drivers or other privileged code. Another provides for monitoring of a specific location in the Executive and halting of the system when it changes. Usually when confronted by problems such as these, one writes a separate program to grab some POOL, load in a trap routine to catch the particular problem at hand, and point a piece of the Executive to this little mousetrap. This becomes a bit more complicated when dealing with an I and D space Executive where these code fragments must reside in ICB POOL and the Executive code itself is write protected. In M-Plus V3.0, hooks exist in the Executive code for detection of Executive data changes as well as catching the addition of an item to the Executive fork list when the same fork block is already there (a double fork). These hooks are assembled based on conditional assembly flags. SYSgen does not define these flags, but users can easily supply them by pausing during SYSgen and editing [11,10]RSXMC.MAC. If you are generating environments for driver and other privileged code development, it makes sense to turn these hooks on so that they can be called upon when needed. .skip 2 .CENTER The Double Fork Test Fork handling is done in Executive module SYSXT, in routine $QFORK. All routines that need to add a fork block to the end of the Exec's fork list end up in $QFORK. In this modules is code conditionalized on the flag R$$FRK. What the conditional code does is look through the existing fork queue and ensure that the block being added is not already in the fork block list. If it ^&is\& found, a double fork is being attempted and the system is bugchecked. Yes - RSX has a bugcheck facility but that, as they say, is another story. When the system is bugchecked, register 4 points to the offending fork block. .TEST PAGE 5 .SKIP 2 .CENTER Watchpoint Support RSX-11M-Plus has a watch point facility. This facility allows monitoring of a location in the Executive for a specific value and breakpointing the processor when its value changes. Again in SYSXT are two pieces of code conditionalized on the flag R$$WPT. The first is in the routine $DIRSV which is called by the DIRSV$ macro from an Exec directive or switch to system state (SWST$, SWSTK) call. The first piece of watchpoint related code is a one-liner as follows: .SKIP 2 MOV####(R5), $WPLST#########; SAVE ADDRESS OF LAST SYSTEM ROUTINE .SKIP What's happening here is that the address of the system state routine which called $DIRSV is saved. In this way we have a record of where the system came from. Next, at the label $DIRXT we have the actual watchpoint code. .skip 2 .NO FILL .NO JUSTIFY CMP $WPVAL, @$WPADR ;;;WATCHPOINT STILL OK ? ;;;ONE OF THE FOLLOWING BRANCHES ;;;SHOULD BE NO-OPED TO START THE ;;;WATCHPOINTS $WPBR: BEQ 1$ ;;;IF EQ STILL OK BNE 1$ ;;;IF NE STILL OK BPT ;;;OOOOOOPPPPPSSS!!! 1$: ;;;REFERENCE LABEL .JUSTIFY .FILL .SKIP If you are wondering where you find the data items being used in the above instructions, you find them in system common (module SYSCM) right before the Executive common APR table. They are: .SKIP 2 .NO FILL .NO JUSTIFY $WPLST::.WORD###0##############;LAST SYSTEM STATE ROUTINE CALLED $WPVAL::.WORD###0##############;VALUE TO WATCH FOR OR AGAINST $WPADR::.WORD###$WPVAL#########;PLACE TO WATCH FOR IT .JUSTIFY .FILL .SKIP 1 What we have here is a way of monitoring a location in Executive data space for a change in a specific value. This location is checked each time the system attempts to leave system state and exit to the user level. In order to do this, RSX must empty the fork queue. The watchpoint code is executed upon return from the system state routine called and before each entry of the fork queue is removed and called. This allows us to see if the system state routine just called or one of the entries removed from the fork queue trashed the location we are interested in. Since the watchpoint code is driven from a table in SYSCM, all that has to be done is to load the address we want to watch into location $WPADR and the value to check against into $WPVAL. A NOP instruction is then deposited at either $WPBR, to catch the system when the location changes to the value in $WPVAL, or at $WPBR+2 to catch the system when the location changes from the value in $WPVAL. Since these data locations and the instruction labels are global Executive symbols, their values can be obtained from the Executive map and loaded using the MCR OPEN command. No special program is required! If you are dealing with an I and D space Executive, then the watchpoint data table should be opened in data space (/KNLD) and the branch instruction should be opened in instruction space (/KNLI). .skip 2 .center How to Enable These Hooks As said, all of this code already exists in the M-Plus Executive. We just have to supply the necessary conditional assembly flags. During SYSGEN, answer YES when asked if you wish to pause to edit any files prior to assembly. The edit [11,10]RSXMC.MAC and add the following conditionals before the executive MACROs section: .skip 2 .NO FILL .NO JUSTIFY R$$FRK=0##############;CATCH DOUBLE FORKS R$$WPT=0##############;WATCHER LOCATION## .JUSTIFY .FILL .skip 1 Now continue with the SYSGEN and the support will be included. RSX-11M users aren't so lucky. They would have to add this code. Watchpoint support is a fairly low overhead operation. However, scanning the fork queue at each fork block insertion can have a negative impact on system performance. Adding a branch around this code at a global Executive label that could be NOPed would be nice. In this way, the double fork check could be enabled by the OPEN command in a manner similar to turning on the watchpoint code. (This last item was not my idea but I liked it when I heard it.) Also, user code may reload $WPLST with more meaningful information during the course of its execution. A piece of key input data or a bit mask showing which portions any suspected privileged code executed are just some useful items that come to mind as being useful information to have available when the system is breakpointed. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT RSX-11M-Plus Data Cache Manager Change .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&RSX-11M-Plus Data Cache Manager Change\& .SKIP .CENTER James P. Tvrdik .CENTER Analysts International Corporation .CENTER 650 Woodfield Drive, Suite 300 .CENTER Schaumburg, IL###60195 .SKIP While installing RSX-11M-Plus Version 3.0 Update D, I noticed (to my great dismay) that disk data caching does not operate in conjunction with the Volume Valid Monitor Program (VVC) published by Gary Maxwell. What occurs is that VVC causes disk data caching to be deactivated for the system disk. The reason behind this is that the data cache manager (DCM) responds directly to ^&any\& QIO issued with the IO.STC (Set Characteristics) function code. Since the VVC program uses the IO.STC function to set the volume valid bit, the first issuance of the QIO$ IO.STC directive causes the cache to be purged and deactivated for the system device. According to Gary, the intent of VVC is to use the IO.STC as a control function (^¬\& a transfer function) for avoiding excessive disk head movement. To correct this problem, I patched the Disk Cache Manager controller source module ([11,10]DCCTL.MAC). The code change causes the requestor taskname to be checked. If it is VVC, then the IO.STC request is queued directly to the driver, thus bypassing the deactivation code. Note that there are alternate solutions such as using the DCM's bypass subfunction bits in the QIO, but since these depend too much on DEC, they are avoided. Create the following correction file in UFD [11,40], insuring that you are patching Version 01.04 of DCCTL.MAC: .SKIP 2 .NO FILL .NO JUSTIFY SY:[11,10]DCCTL.MAC;2/AU/-BF=SY:[11,10]DCCTL.MAC;1 \ -3,3,/;JPT001/ .IDENT /01.04A/ -25,25,/;JPT001/ ; ; J. P. Tvrdik 01 April 1987 01.04A ; AiC, JPT001 ; ; Install checks to verify the requestor task ; as the Volume Valid Monitor (VVC) program ; (from DECUS). If it is, the IO.STC function ; should be passed directly to the driver and ; NOT interpreted by the Disk Cache Manager ; (DCM11M). ; % -73,73,/;JPT001/ MOV I.TCB(R1), R2 ; Pick up TCB of requestor CMP T.NAM(R2), _#_^_^RVVC ; Is it VVC ? BEQ 20$ ; If EQ, yes / .JUSTIFY .FILL .SKIP Now apply the correction file to the source file using the SLP source patcher, and assemble the patched module: .SKIP 2 .NO JUSTIFY .NO FILL SET /UIC=[11,10] SLP @[11,40]DCCTL.COR SET /UIC=[11,24] MAC DCCTL,[11,34]DCCTL/-SP=[1,1]EXEMC/ML,- -> [11,10]RSXMC/PA:1,DCPRE/PA:1,DCCTL .JUSTIFY .FILL .SKIP Replace the module into [1,24]RSX11M.OLB, saving the old one if you desire, then re-Taskbuild the Disk Cache Manager (DCM11M): .SKIP 2 .NO JUSTIFY .NO FILL SET /UIC=[1,24] LBR DCCTL.OBJ=RSX11M.OLB/EX:DCCTL LBR RSX11M.OLB/RP/-EP/SZ=[11,24]DCCTL TKB @[200,200]DCM11M .JUSTIFY .FILL .SKIP Now create and VMR a new system image file: .SKIP 2 .NO JUSTIFY .NO FILL SET /UIC=[1,54] PIP RSX11M.SYS/NV/CO/BL:1026.=RSX11M.TSK VMR @SYSVMR .JUSTIFY .FILL .SKIP Since the Disk Cache Manager is installed as a directive common, a new SYSgen is ^¬\& required. Simply BOOt the new image, SAVe it and write the boot block. This change has been implemented on a client's host computer and appears to work quite well. My thanks to Gary Maxwell for his time and assistance. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Removing FMS from INDirect .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&Removing FMS from INDirect\& .SKIP .CENTER Gary Maxwell .CENTER U.S. Geological Survey .CENTER Office of Earthquakes, Volcanoes and Engineering .CENTER 345 Middlefield Road, M977 .CENTER Menlo Park, CA###94025 .SKIP How many people use the FMS-11 interface available with Indirect (...AT., the @ command processor)? For the eight of you who raised your hands, the following won't concern you. But for the rest of us, here is a way to get back some space in your system. A lot of people don't realize that FMS-11 builds into the task image of Indirect, and that it is big. Really big. But you can remove all the FMS code very simply and reduce the size of the task image to something reasonable. Create the following SLP correction files using your favorite text editor: .SKIP 2 [1,40]ICMBLD.COR: .SKIP .NO FILL .NO JUSTIFY ICMBLD.BLD;2/-AU=[1,20]ICMBLD.BLD;1 -/EXTBUF/,. _.; .SETN EXTBUF 4000 ! Space for FMS-11 buffer .SETN EXTBUF 0 ! No space for FMS-11 buffer -/$FORMS/,. _.;.IFT $MINST .DATA GBLDEF=$FORMS:0 ; No FMS-11 present .DATA GBLDEF=$FORMS:0 ; No FMS-11 present / .JUSTIFY .FILL .SKIP 2 [1,40]ICPCOMBLD.COR: .SKIP .NO FILL .NO JUSTIFY ICPCOMBLD.BLD;2/-AU=[1,20]ICPCOMBLD.BLD;1 -/ICM:/,. ;ICM: .FCTR ROOT-IGTN-IL-GTKN-EXED-FORM-NETW,FDRV ICM: .FCTR ROOT-IGTN-IL-GTKN-EXED-EGCML-NETW -/ICMFSL:/,. ;ICMFSL:.FCTR ROOT-IGTN-IL-GTKN-EXED-FORM-NETW,FDRV ICMFSL: .FCTR ROOT-IGTN-IL-GTKN-EXED-EGCML-NETW -/ICMRES:/,. ;ICMRES:.FCTR ROOT-IGTN-IL-GTKN-EXED-FORM-NETW,FDRV ICMRES: .FCTR ROOT-IGTN-IL-GTKN-EXED-EGCML-NETW ; EGCML: .FCTR ECM1-ECM2-ECM3 / .JUSTIFY .FILL .SKIP Now perform the following commands to apply the patches and rebuild Indirect: .SKIP 2 .NO FILL .NO JUSTIFY SET /DEF=[1,20] SLP @[1,40]ICMBLD.COR SLP @[1,40]ICPCOMBLD.COR SET /DEF=[200,200] @SYSGEN .JUSTIFY .FILL .SKIP Go to the non-privileged task build section of SYSgen and build your favorite version(s) of Indirect (ICM, ICMRES, or ICMFSL). You will be pleasantly surprised to find that the new Indirect is 61% smaller than before. ^IS144^GEditor's note: If you feel bold, apply these patches before you do SYSgen. Then you don't have to redo the non-priv task build section.^IS204^G .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Response to February "Bag of Tricks" .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&Response to February "Bag of Tricks"\& .SKIP ^IS144^GEditor's note: The following is a response to the February "Bag of Tricks" article on the Extend Task (EXTK$) directive. More comments follow the letter.^IS204^G .PAGE # .PAGE The Editor responds: ^IS144^GYes, it's true. In current RSX systems the Task Loader loads the task using the unextended size, and allocates the additional space. It takes significantly more time for a task to extend using the Extend Task directive than it does to load it already extended. If a task always requires extra buffer space, it should obviously be built into the task and not obtained through extensions of any kind. If much free memory is available on the host system, and the task often benefits by being installed with an extension, this is preferable to doing runtime extends. However, it is never safe to assume for a task to assume that it is already pre-extended. It must find out. That's why the GTSK$ and GPRT$ directives exist. Using GTSK$ and GPRT$, the task can determine if it is already extended to its limit. If it is not, it can extend itself as far as necessary. The February issue was very short of submissions, and Mr. McGlinchey very kindly agreed to let me ghostwrite the original article using his by-line. The Editor is not as expert as some users in the intricacies of RSX, and made an incorrect statement. I apologize for any inconvenience this may have caused the readership. ^IS204^G .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Security of the RSX-11 Operating Systems .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&Security of the RSX-11 Operating Systems\& .SKIP .CENTER Thomas R. Wyant III .CENTER E. I. DuPont de Nemours _& Co., Inc. .CENTER Textile Fibers Department .CENTER Richmond, VA###23261 .SKIP This article had its origin as a "hacker's cookbook" for RSX. Therefore, the various routes of entry are discussed in some detail. There are some who believe that this kind of thing gives people ideas, and should not be done. I disagree. I feel that any responsible system manager wants to know what the threats to his system are, so he can counter them. I have collected here some of the more notable security issues - and non-issues - that I have encountered (and occasionally exploited) in the RSX operating systems. It is not intended to be exhaustive - but then Godel's Incompleteness Theorem implies that no discussion of security can ever be exhaustive. There are, however, two principles that lie behind almost all the issues raised here: .SKIP .LM +3 .INDENT -3 o##Know what your users are doing. The best logical security in the world is no good if the users are doing some of the things mentioned here. .SKIP .INDENT -3 o##Protect the physical system. This includes CPU, media, and so on. If you don't have physical security, you don't have any other kind, either. .LM -3 .SKIP 2 .CENTER Backup Media There is an obvious problem with backup media: it is normally off line. Unless it is guarded in some way, it can be spirited out, copied, and returned, leaving no trace of tampering. The situation can be worse if the backup is of the system pack, as the account file resides there. The possessor of system backup media can read accounts and passwords from it, and thereby gain privileged access to the system. Whether this is a problem depends on how the backup was created, as follows: .SKIP .LM +3 .INDENT -3 o##PIP - Account file is present only if explicitly copied. .INDENT -3 o##PRESRV - Account file always present. .INDENT -3 o##DSC - Account file always present. .INDENT -3 o##BRU - Account file is present only if the whole system disk was copied, or if a selective BRU copied it explicitly. .LM -3 One might think that the M+ user would not be at risk from loss of passwords by this route, as the passwords are encrypted in the file. However, encryption is not complete protection. The passwords can still be obtained by the brute force method of encrypting potential passwords, and comparing the output of the encryption algorithm to what is actually in the account file. This is discussed more fully under "Brute Force". The only solution is to be aware of which backup media have the account file on them, and control those media. .SKIP 2 .CENTER Front Panel The front panel (whether switches, pushbuttons, or console processor) available on most PDP-11s represents a very crude but unrestricted means of entry to the system. Even an unsophisticated person can bring a system down simply by pushing the "HALT" button. A sophisticated user can log his terminal on or grant it privileged status in a matter of seconds. The procedure for this is given below: Taskbuild the system's symbol table using the command .SKIP >TKB ,TI:/-WI=LB:[1,54]RSX11M.STB .SKIP By default, any user has the required access. In the Taskbuilder map, find the Unit Control Block (UCB) address of the terminal to be made privileged. For terminal TTnn:, this address appears as the value of the symbol ".TTnn". For an RSX-11M system, or an RSX-11M+ system without I and D space support, this value is the physical address of the UCB, and you can skip the next step. For an RSX-11M+ system with I and D space support, the symbol $EXEND appears in the Taskbuilder output. Compute the physical UCB address by: .SKIP .LM +3 .INDENT -3 o##Round $EXEND UP to next 32 word boundary (i.e., add 77 octal, then make the last 2 digits zero). .SKIP .INDENT -3 o##Subtract 20000 octal (4KW for the ICB pool, which is mapped by both I and D space APR 0). .SKIP .INDENT -3 o##Add the value of the symbol ".TTNN". .LM -3 .SKIP The result is the physical address of the UCB for TTnn:. Calculate the physical address of the second unit status word for TTnn: by adding 12 octal to the physical address of the UCB, calculated above. Halt the processor and examine the second unit status word using console ODT. Calculate a new value for the second unit status word, which is the old value, but with bit 3 (10 octal) set, to grant privilege. Also clear bit 8 (400 octal) to log the terminal in if necessary. In other words, .SKIP new value = ((old value)_&177377)!10 Patch complete. Continue the processor. When we tried this on an 11/70 running RSX-11M+, the CPU was halted for less than 10 seconds. This outage might not be noticed on a lightly loaded system, and on a heavily loaded one, might be attributed to CPU load. The only lasting side effect was that the system's time of day clock was off by the amount of time spent halted; this would not be noticed in most shops. There are two ways to block this means of entry: .SKIP .LM +3 .INDENT -3 o##Restrict access to the front panel. Lock it when it's not in use. .SKIP .INDENT -3 o##Protect [1,54]RSX11M.STB as you would the account file. This includes watching backup media, and reprotecting it so that the world has no access. .LM -3 .TEST PAGE 5 .SKIP 2 .CENTER System Console Terminal Sometimes, the console terminal is left logged on and privileged. If it is left unattended, anyone can use it for their own purposes. I have seen this problem dealt with by doing a .SKIP SET /SLAVE=TI: .SKIP at the start of the login command file, and .SKIP BYE .SKIP at the end. Another approach is to set the console to a custom CLI. However, this still leaves a window when the system is booted. At system boot, someone at TT0: can issue a control/C as soon as the system comes up, followed by the command .SKIP MCR>REM ...AT. .SKIP Of course, this means the startup command file does not get run, and the console terminal is left logged on and privileged. There are two ways to block this means of entry: Restrict access to the console terminal, and/or slave the console in the system image by: .SKIP VMR>SET /SLAVE=TT0: .SKIP In this case, the console terminal comes up slaved. Note, however, that if you log the console off, it becomes unslaved again. .TEST PAGE 5 .SKIP 2 .CENTER DECnet The main problem with DECnet is the DAP utility set (NFT/FAL). If you have enabled access verification nowhere else, enable it for FAL (DECnet object number 17) and you will sleep sounder. Remote task control (object 15) is another good candidate. .SKIP 2 Remote Command File Submission If remote command file submission is available on the local node, the user can submit a command file that issues a .SKIP >SET /PRIV= .SKIP command on his terminal. This works if the _.CMTS. task submits the command file directly to the indirect command processor, and the terminal used is logged on as a privileged terminal. In some M+ systems, it also works if _.CMTS. submits the command file to the batch processor, and the submitter specifies a UIC that does not exist. Any of the following will help reduce this problem: .SKIP .LM +3 .INDENT -3 o##Don't install _.CMTS., or remove it after DECnet installs it. .SKIP If you must use _.CMTS., use it with the batch processor if possible (and if you are not running the vulnerable version of _.CMTS. mentioned above). .SKIP .INDENT -3 o##If you must have _.CMTS. spawn command files to a terminal, have them executed on a nonprivileged terminal. The TI: of the spawned command file is controlled by a LUN assignment on _.CMTS.. .LM -3 .SKIP 2 Access Control in Global Aliases If access control information (account and/or password) is embedded in any global aliases, any user can issue the .SKIP >NCP SHOW ALL ALIASES .SKIP command, and select the alias which best suits his needs. It is true that DECnet refuses to display the password associated with an alias, but the account number or user name (which is displayed) is enough to tell if a given alias is of interest. Global aliases with privileged access control are particularly to be avoided. Such aliases can be used (among other things) to read the account file for the designated node with commands similar to: .SKIP >NFT ACNT.TMP=alias::[0,0]RSX11.SYS .BREAK >DMP TI:=ACNT.TMP/AS/OC Avoid the use of global aliases that have access control associated with them. .SKIP 2 Worms In case anyone is still unacquainted with the terminology, a "worm" is a program or other procedure that copies itself from node to node around a network, getting itself executed on each node it visits, and possibly doing (by chance or design) deleterious things along the way. Unlike VMS, there is no way under RSX for a person off-node to either install a task, or run an uninstalled task other than use remote command file submission, as discussed above. Assuming this rat hole is plugged, I can't get terribly excited about this as a security threat. However, the loading of a Trojan Horse (discussed below, under "Guile and Stealth") is still a possibility. .TEST PAGE 5 .SKIP 2 .CENTER Brute Force Brute force password cracking is unlikely for reasons that will be discussed here. .SKIP RSX-11M RSX-11M and old versions of RSX-11M+ are considered by some to be insecure because of the shortness of their password (6 characters). This does not appear to me to be a serious threat, provided that passwords are chosen "at random", so that there is no way to restrict the search for valid passwords, and that all passwords are 6 characters long. In order to show this, a calculation of the time required for an exhaustive search of all passwords less than a given length is in order. For this calculation, assume that a single password can be tried in one second, using automated equipment. The actual figure depends on several factors (such as line speed and system load), but should not be much less than this. According to the System Management Guide, a total of 41 characters are valid in passwords. Time required to search all passwords less than a given length is then: .SKIP .NO FILL .NO JUSTIFY Ch Paswrds Search Time -- ------- ------------ 0 1 1 second 1 42 42 seconds 2 1723 28.7 minutes 3 70644 19.6 hours 4 2.89E+6 33.5 days 5 1.19E+8 3.76 years 6 4.87E+9 154 years .JUSTIFY .FILL Obviously the average time to find a password is only half this, but the numbers are still sufficient. .SKIP 2 RSX-11M+ Current versions of RSX-11M+ allow much longer passwords (39 characters), and encrypt the copy of the password that is in the account file. As password length increases, the time required to get in by brute force quickly becomes many millennia, as long as the passwords continue to be chosen "at random". However, the user of the brute force method can speed his task considerably if he can obtain a copy of the account file from insufficiently protected backup media. He can generate and encrypt his own passwords and compare the encrypted values to what is in the account file in milliseconds rather than seconds per attempt. The best way to counter this is to be careful with the account file itself. Longer passwords can also help, as even milliseconds can be stretched to millennia by requiring enough of them. .TEST PAGE 5 .SKIP 2 .CENTER Guile and Stealth There are, unfortunately, better ways than brute force to obtain a password. The literature and personal experience suggest that several things can cause problems. .SKIP 2 Non-random Passwords There is a tendency for naive users to select trivial passwords. First names, initials, license numbers, and so forth are easy to guess. The only solution here is the education of users. A periodic audit of dumb passwords might catch the worst offenders. .SKIP 2 Hardcopy Passwords HELLO allows the password to be specified on the same line as the uic as: .SKIP >HEL uic/password .SKIP This is bad news anywhere, but particularly on a hardcopy terminal. The literature suggests that passwords are commonly lost in this way, when someone with an eye out for 14.5 x 11 paper plows through the right dumpster. There are two possible solutions. One is to educate the user. The other is to patch HELLO (see old SIG tapes) to overprint the login line when this form of login is used. If DEC would disable this form of login, allow the system manager the option of disabling it, or overprint the line, the problem would be relieved. .SKIP 2 Automated Logins I have seen people who save themselves the trouble of remembering their passwords by programming the login command into a terminal's answerback message. Unfortunately, this allows anyone to use it. Educate the users. Or cut the terminal's answerback enable jumper. This practice is fairly easily audited for. .SKIP 2 Password Grabbers Since RSX allows any user access to an unowned device, a nonprivileged user can write a program that simulates the behavior of ...HEL. Being nonprivileged, he cannot of course log his victim in, but he can record the victim's password and then issue an appropriate error message and exit his program. The user then has access to the real ...HEL and can log in normally, believing (the hacker hopes) that he made a typo on his password. The only general solution is vigilance on the part of the user. Perhaps DEC will consider the option of having logged out terminals allocated to CO:, though after doing this comes the problem of how to get ...HEL to run. .SKIP 2 Trojan Horses Like many hacker's tools, a "Trojan Horse" is a program or command procedure with undocumented functionality that is possibly deleterious to your system. The distinguishing feature of a Trojan Horse is that it requires the unwitting cooperation of someone on the victimized system, as (unlike a worm) it has no means of securing its own execution. The main sources for unscrutinized code are load media and networks. The prudent system manager is cautioned to be familiar with the origin and content of anything loaded onto his system, and to allow network access only under the same conditions as login access would be allowed. Like all the issues raised under "Guile and Stealth", informed and cooperative users are vital to the defense against this attack. .SKIP 2 Things You Haven't Thought of Yet Some users are sophisticated enough to do unanticipated things to mess you up, or are unsophisticated enough to do unanticipated things to mess themselves up. You may be better off restricting their actions to a list you control. There are several ways of controlling which programs the user has access to: A "captive account" can be created simply by setting up the account to be logged on slaved, and using the person's LOGIN.CMD to provide the command interface. Capture can be made almost complete by issuing a .SKIP _.ENABLE CONTROL-Z .SKIP before the first query issued, to prevent "Control/Z" bailout on a _.ASK directive. If you omit this, the user will still have a slaved terminal when LOGIN.CMD exits, and you will have to get him straight. A subtle point in this approach is that the user should have read-only access to both his own login command file and the directory in which it resides - otherwise, a number of seemingly harmless applications (such as mail) allow him to modify his own LOGIN.CMD. I can think of two ways to approach this: .LM +3 .SKIP .INDENT -3 o##Protect the user's home directory and the files in it read-only for owner and group. If the user has need to create files, set his default to some other directory in his LOGIN.CMD. .SKIP .INDENT -3 o##Have SYSLOGIN.CMD chain to some file other than LOGIN.CMD for a terminal that is logged on slaved. .LM -3 It is possible to write a CLI that restricts the user to a subset of the full list of MCR commands. A quick way to do this is to obtain CCL (from the KMS/Fusion package, on several recent SIG tapes) and modify it: .SKIP .LM +3 .INDENT -3 o##Remove the functionality that spawns unrecognized commands to MCR. .SKIP .INDENT -3 o##Clean out the memory-resident command table. .SKIP .INDENT -3 o##Remove the search of SYSCLI.CCL for commands. .SKIP .INDENT -3 o##Modify the open operation on USERCLI.CCL so that this file can be stored in a protected directory. .LM -3 .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT The Notebooks of Justin L. Hewser .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 .CENTER ^&The Notebooks of Justin L. Hewser\& .SKIP .CENTER Gary Maxwell .CENTER U.S. Geological Survey .CENTER Office of Earthquakes, Volcanoes and Engineering .CENTER 345 Middlefield Road, M977 .CENTER Menlo Park, CA###94025 .SKIP While sitting near the back of a recent Symposium Q_&A session I observed a commotion occuring both at the microphone and at the panelists' table of the panelists. Someone named "Justin L. Hewser" was insisting that the RSX group should build the M-Plus batch processor against RMSRES with DAPRES support, so he could batch across the net. Well, he didn't get the answer he or I wanted, for it sounded like a good idea to me, too. When I discussed it with Mr. Hewser, he pushed up his dark glasses, looked about nervously, gave me a floppy disk, mumbled something about having to get out of town fast, and hurried away without giving me an explanation of the contents of the disk. After returning home, I eagerly looked on the disk to see what I had. The following is a condensation of the contents. .SKIP 2 .LM +10 .RM -5 ^IS144^G*S006. -- Linking the Batch Processor to RMSRES .SKIP We have up to twelve batch processors active. BPR links against RMS. Why not RMSRES? Why not DAPRES? Too much of a resident library is really a good thing. .SKIP The solution is really easy. Create the following correction file in UFD [1,40]: .NO FILL .NO JUSTIFY .SKIP BPRBLD.BLD;2/-AU=[1,20]BPRBLD.BLD;1 -/PAR=/ .DATA ; .DATA ; Link to RMSRES/DAPRES .DATA ; .DATA CLSTR=RMSRES,DAPRES:RO -/GBLDEF=D$ELPS/,. .DATA GBLDEF=D$ELPS:1130 -/@BPRRMS.ODL/,. _.; .DATA @BPRRMS.ODL .DATA @LB:[1,1]DAPRLX.ODL / .JUSTIFY .FILL .SKIP Change the default job CPU time limit from the incredibly short three minutes to 10 hours by changing the global definition of D$ELPS. You choose any limit in minutes, convert to octal, and use that instead of "1130" above. .SKIP Next, patch everything by performing the following steps: .SKIP .NO FILL .NO JUSTIFY >SET /DEF=[1,20] >SLP @[1,40]BPRBLD.COR >SET /DEF=[200,200] >@SYSGEN .JUSTIFY .FILL .SKIP You can then redo the privileged task builds to build a new BPR and batch across the net. .SKIP You can't link it as a multi-user task. No such luck. Everything is in the blank PSECT. Thanks a lot, DEC.^IS204^G .LM -10 .RM +5 .SKIP Ah, yes. Where shall we begin here? Justin's fundamental idea ^&is\& sound. Assuming that you already use RMSRES for other tasks in the system, linking the batch processor to RMSRES trims about 3.5 Kwords from the task image (a 35% reduction) and trims the same amount from the total physical memory demands on the system. So far, pretty good. Batching across DECnet is an interesting if not bizarre idea. However, there is more to DECnet remote file access than linking to the Data Access Protocol resident library, DAPRES. Alas, as the reader may discover, all other batch components speak FCS, not RMS. Network file specifications cannot be entered into QUEUE.SYS. There is also another consideration: Why is Justin mapping RMSRES as a user-mode library? This is M-Plus, remember. His system probably supports supervisor mode. Mapping RMSRES in supervisor mode peels out most of the RMS overhead in the task and often allows "flattening" of a task through reductions in overlay complexity. And a 10 hour default CPU time limit seems excessive when the default can be overridden at submission time. There are gains available in the batch processor, but this is not the best way to do it. If you want to build the batch processor against RMSRES in non-supervisor mode, replace the lines: .SKIP _.DATA CLSTR=RMSRES,DAPRES:RO .BREAK _.DATA @LB:[1,1]DAPRLX.ODL .SKIP in Justin's procedure above with the following: .SKIP _.DATA LIBR=RMSRES:RO .BREAK _.DATA @LB:[1,1]RMSRLX.ODL .SKIP and pick some default CPU time limit which produces a reasonable result. There is a lot of other information on the floppy. I have just now begun to examine it in detail. Here are some candidates for future columns: .SKIP o##Cacheing Memory-Resident Disks to Decrease Access Time .BREAK o##Intertask Communication using CINT$ and PIRQ .BREAK o##Building Unmapped RSX-11M-Plus for the 11/03