CLAYTON@xrt.upenn.EDU ("Paul D. Clayton") (03/16/87)
War Stories From TSO Financial - The Saga Continues... Chapter 2 - Sunday, March 15, 1987 Being in a banking environment with over 500 users spread between 17 buildings up and down the east coast, the use electronic mail becomes the major issue in communications. The solution when you have VMS is to use VMS MAIL and the days of telephone tag are but a lingering memory. The other MAJOR problem being in the banking environment is one of security and attempting to satisfy the auditors, both internal and external. In our attempts to place controls on what users can do, each has a login menu that presents them with access to what they need. The problem is the third party and in-house systems that were written with little or no thought about the restricted use of privileges. The idea of, 'give me SETPRV and I'll take what I need' is the prevalent theme. I can live with, to a limited degree, this attitude if the user can never get to the DCL prompt. Alas this is (was) my beef with the VMS MAIL program, and its providing the SPAWN command. Last week I reached by limit with people getting to DCL through MAIL and traveling around the system with excessive privileges. The net result was time spent with the fiche and patching the MAIL image so as to disable the SPAWN command. Note that this only removes the SPAWN command from MAIL, and as far as I have been able to tell, does not impact other aspects of MAIL operation. I have included the patches to the MAIL images for versions 4.2 to 4.5 of VMS. Note that the patches are different between version 4.2,4.3 and 4.4,4.5. You have to select the patches that you need based on the version of VMS you are running. I suggest that you COPY the current image of MAIL to a file named MAIL.EXE_V4X, where X represents the current version you are running. PREVIOUS to performing any updates to VMS, this MAIL.EXE_V4X file needs to be copied to the highest version of MAIL.EXE so that VMSINSTAL will work correctly. I have been using the patched images for some time now and everything, except SPAWN, works as before including SEND/EDIT. It should also be noted that the MAIL$EDIT logical name should be define to be one of the following selections. $define mail$edit "CALLABLE_TPU" $define mail$edit "CALLABLE_EDT" The use of the logical name in referencing a command file does not work at the moment, according to an article in DSIN, for all cases. The patches for VMS 4.2 and 4.3 of the MAIL image are as follows. $PATCH/NOJOURNAL SYS$SYSTEM:MAIL.EXE DEFINE BASE = 08BD7 !BASE ADDRESS TO PATCH INTO REPLACE/INSTRUCTION BASE !NOW WE PUT JUMP OVER SPAWN "MOVAB L^00001471,R9" !ORIGINAL INSTRUCTION AFTER REGISTER MASK EXIT "BRW 08CE4" !BRANCH TO NORMAL RETURN EXIT UPDATE !CREATE A NEW IMAGE WITH CHANGES EXIT !EXIT FROM PATCH UTILITY The patches for VMS 4.4 and 4.5 of the MAIL image are as follows. $PATCH/NOJOURNAL SYS$SYSTEM:MAIL.EXE DEFINE BASE = 0ACA8 !BASE ADDRESS TO PATCH INTO REPLACE/INSTRUCTION BASE !NOW WE PUT JUMP OVER SPAWN "SUBL2 #18,SP" !ORIGINAL INSTRUCTION AFTER REGISTER MASK EXIT "BRW 0ADDD" !BRANCH TO NORMAL RETURN EXIT UPDATE !CREATE A NEW IMAGE WITH CHANGES EXIT !EXIT FROM PATCH UTILITY I hope that these patches help anyone that is having problems with MAIL and inquisitive people with time on their hands. Paul D. Clayton - Systems Manager TSO Financial - Horsham, Pa. USA Address - CLAYTON%XRT@CIS.UPENN.EDU
8004SLB@mucsd.UUCP (Sandy) (03/17/87)
Simply setting the CAPTIVE flag on a username using the AUTHORIZE utility disables the SPAWN command within MAIL regardless of the privilege of the user. This would seem to be easier to implement than patches to the MAIL image. At least this is the case with V4.4 of MAIL and up. --Sandy Berger Marquette University Computer Services Division Technical Services UUCP: ...!seismo!uwvax!uwmacc!uwmcsd1!marque!mucsd!8004slb ARPA: marque!mucsd!8004slb@csd1.milw.wisc.edu
TLI%Sargas@USC-OBERON.ARPA (Tony Li) (03/17/87)
Gee, have you patched everything that you can spawn out of? How about Teco? Or is that circumvented by inaccessibility through your menu system? Tony ;-) -------
oberman@LLL-ICDC.ARPA ("Oberman, Kevin") (03/17/87)
>I can live with, to a limited degree, this attitude if the user can never >get to the DCL prompt. Alas this is (was) my beef with the VMS MAIL program, >and its providing the SPAWN command. > >... > >I hope that these patches help anyone that is having problems with MAIL and >inquisitive people with time on their hands. A very useful patch for VMS V4.2 and V4.3. But the VMS developers fixed this problem in V4.4. If the CAPTIVE flag is set in the account's UAF record the SPAWN command is disabled with a message that SPAWNing is not permitted from CAPTIVE accounts. If you want to keep users out of DCL, their accounts should ALWAYS be captive. By the way - TPU also has a SPAWN command. (As does CALLABLE_TPU.) R. Kevin Oberman LLNL arpa: oberman@lll-icdc.arpa (415) 42222eahORNORNOt
u3369429@murdu.OZ.AU (Michael Bednarek) (03/18/87)
In article <8703161912.AA04523@linc.cis.upenn.edu> CLAYTON@xrt.upenn.EDU ("Paul D. Clayton") writes: >Being in a banking environment with over 500 users [...] >The other MAJOR problem being in the banking environment is one of security >[...] each has a login menu that presents them with access to what they need. >[...] The idea of, 'give me SETPRV and I'll take what I need' >[...] people getting to DCL through MAIL and >traveling around the system with excessive privileges. The mind shudders. Why not install those images with privileges? When the image exits, the user is left with her/his default privileges. >I can live with, to a limited degree, this attitude if the user can never >get to the DCL prompt. Alas this is (was) my beef with the VMS MAIL program, >and its providing the SPAWN command. Why not do the obvious and make every account CAPTIVE (UAI$V_CAPTIVE) ??? Apart from the fact that without it every one of your users can login without executing your smart login menu, it will also disable SPAWN from within MAIL. Really, I can't believe you are running your system with non-captive accounts. Michael Bednarek (u3369429@murdu.oz.au)