WIZARD@RITA.ACS.WASHINGTON.EDU ("The Bandit . . . ", on RITA) (05/17/88)
Scott Allen (Exactly how long is a uFortnight ? <SCOTT@GUVAX>), responding to Mark Wood, wrote: > >Subj: More on protection of SYS$SYSTEM files and VMS 4.6/4.7 > > > >I have scanned our SYS$SYSTEM and found some interesting protection masks. > >For example, can anybody think of a good reason for SYS.EXE to be W=RE? > >Or *every* device driver? I don't know whether the 4.6 installation did > >this, but I'm going to suggest that our site review these masks carefully. > >Mark H. Wood IMHW400@INDYVAX.BITNET (317)274-0749 > No. No. Yes it did, and I suggest you do so. > . . . > I would like to know the reasoning behind the protection masks in > sys$system that are put on files during an upgrade of vms. eg. Why > is the sys$system directory and most of the files W:RE? > > Why not have the system directories Execute-Only as default to disallow > non-privileged directory scans. How about authorize or sysgen ? > Why are they W:RE ? Answer: It has to do with the INSTALL utility and sharing of memory images. I discovered this one quite some time ago. One of our systems was on its knees begging to be put out of its misery. The problem was that the PASCAL.EXE image had its protections set to W:E, not W:RE. As a result, none of the code pages that would normally be shared were. Each process using the Pascal compiler had its OWN copies of any needed pages. (This can be seen using the SHOW PROCESS /CONTINUOUS "V" option. Shared pages are noted with a "G", and user pages with a "*".) If you want to prohibit directory scans, you could merely change the protection on the SYS$SYSROOT:SYSEXE.DIR file, but I don't know if that would void the sharing of code. As for AUTHORIZE.EXE, ask yourself why it is INSTALLed, by default, with CMKRNL! (We remove it.) SYSGEN shouldn't be a problem as a user shouldn't be able to change anything. Answer courtesy of: Derek Haining Academic Computing Services University of Washington Seattle, Washington (206) 543-5852 DEREK@UWARITA.BITNET -or- DEREK@RITA.ACS.WASHINGTON.EDU P.S. The only disclaimer I will put here is that this problem was discovered quite some time ago, and may not be applicable in VMS V4.6 or higher. (We are still at V4.5.) If anyone cares to check it out, I would be interested in knowing the outcome.