EVERHART%ARISIA.DECnet@GE-CRD.ARPA (04/14/88)
The VMS security patch for VMS 4.7 which just came out did not prevent BOSS or other programs from working in my environment. However, that may be because device protection for devices TPA0 and PYA0 (the virtual terminals) is 0. This can be arranged separately for them and I think it's also affected by the sysgen parameter tty_prot which can be set to 0 for this. This may be a less intrusive way to get PHOTO or BOSS running again without giving everyone READALL all the time :-) Flame on In following the discussion of DEC's security policy and reasons for it, I must agree with Dan Graham. The DEC view of the world is flawed in that crackers DO already communicate. Result is that the "bad guys" ALREADY know how to do breakins, at least in the case of those for whom it's a hobby. DEC developers know about some of these methods. And meanwhile those of us who try to keep our (networks of) VAXen running to do hopefully useful work are left in the dark. This not only gives the crackers an unconscionable advantage; it promotes false feelings of the general security of the VMS environment and discourages that constructive paranoia which should be felt by system managers about the dangers of trusting their equipment and systems software too strongly. (Another feature of such paranoia is having GOOD backup practices so that the online and volatile exposure to loss is minimized.) I'd like to see DEC let us know at least about those security problems which have been discovered outside of Digital. Having a security problem reported to DEC from the outside should be sufficient evidence of this. (It's not a good idea to discourage DEC employees from fixing these bugs which they may find internally and which outsiders have NOT reported. Thus, an internally found bug may reasonably be fixed quietly and nobody's performance rating need suffer.) I think it's important further that those bugs that result in "mandatory patches" should be WELL described to us, so that non-DEC software breakage can at least be predicted. Having the cryptic note "install this NOW to protect yourself" without letting us know that some of our software (e.g. photo) might break is unconscionable. I gather that the device protection business is part of the problem set addressed. Can anyone (inside DEC or out) tell us, does it have to do with someone writing to or attaching VT or LAT jobs that are detached? Does it have to do with writing to intelligent terminals that are owned by other jobs? In other words, just WHERE is the exposure, and does it go away if we stop using VT terminals or LAT terminals? Can we get around the problem in another way? Perhaps some image and daemon which would change the device protections after logins or spawns? We need to know this stuff, and given the good communications many crackers enjoy, we don't open things that much more by talking about them openly. I might add, disassembling the newly supplied images and the old ones and using DIFF allows one to find where changes were made. Given a good disassembler (like the one on the SIG tapes which Rick Pavlin wrote), this business of DEC trying to make the fixes hard to reverse engineer seems like another case of head in the sand... Flame off Disclaimer: These opinions are my own. As if anyone cared about them anyway, I reserve the right to deny they exist. I will respect the wishes of someone replying directly who doesn't want the reply shared, but suggest that discussions of software, like software itself, should be shared.... Glenn Everhart Everhart%Arisia.decnet@ge-crd.arpa