Magill@UPENN.CSNET (MSCF Operations Manager) (11/17/85)
One aspect of the security issue overlooked in the discussion is DEC's concern about security. They don't really care about security - They will give ANYBODY with the $$ the COMPLETE documentation to the security system. Andy is concerned with corporate vanity not Security. ........ If you are really serious about security one implements a program such as Sperry's. An OS/1100 site nominates a Security Office to Sperry in writing. That individual is contacted by Sperry and required to sign a "security pledge" (my term). Then they are given one copy of the Security documentation which is printed on special anti "xerox" paper etc. This person now has a legally enforceable responsibility and obligation to safeguard security information both for his company and for Sperry. He has had these responsibilities explained to him and has affirmed that he understands and will abidie by them. Sperry is serious about security and has many government sites who are also serious about security. Clearly DEC is not. ........ Any operating system which does NOT PERMIT its backup system to enforce standard labels can't even joke about security - they simply don't give a damm. Any system which permits ANY user to arbitrarily overrule standard ANSI tape labels cannot even jokeingly talk about secureity. I can not even protect my backup tapes from users except by physically locking them up. ........ By the way, don't get me wrong, I like VMS. It's the best operating system on the market since Sperry capped the old RCA TSOS (later VMOS, later VS/9) operating system.... Funny VMS appeared about the same time as VS/9 was capped... there seem to be an awfully lot of people at DEC from Woster Polley and a surprisingly large number of VMS developers who seem to know all about IDA. Now if I could just find someone to explain WHY VMS has such a wierd paging/swapping algorthym.... Did it ever get published? What's wrong with demand paging? Demand Enough is enough already.... Bill Magill Operations Manager Moore School Computing Facility University of Pennsylvania Magill@upenn-lrsm.csnet-relay
info-vax@ucbvax.UUCP (11/21/85)
> From: Magill@UPENN.CSNET (MSCF Operations Manager) > Date: 17 Nov 85 02:57:00 GMT > One aspect of the security issue overlooked in the > discussion is DEC's concern about security. > They don't really care about security - They will give > ANYBODY with the $$ the COMPLETE documentation to the > security system. If there aren't any holes in it, giving people the manual will gain them nothing. If there are holes, hiding the manual won't help for long. DEC's security features are the fairly standard ones. > Any operating system which does NOT PERMIT its backup > system to enforce standard labels can't even joke about > security - they simply don't give a damm. Anyone who believes any scheme of labeling will protect tape security is a fool. I'll just take your Sperry tapes and read them on my Unix system, laughing at your tape labels saying I don't have permission. The Unix 'ansitar' program is too dumb to understand the protection labels. Fix it, you say? How? The source is public domain, as is the ANSI standard. > Any system which permits ANY user to arbitrarily overrule > standard ANSI tape labels cannot even jokeingly talk > about secureity. I can not even protect my backup tapes > from users except by physically locking them up. You mean you let anyone who wants to mount a tape on your tape drives? As long as one such system exists in the world, no ANSI tape is secure. All the tape labels can do is protect against accidental destruction of good data. Of course you can't protect your backup tapes from users without locking them up! Anyway, what if your facility burns down? You should have at least some backups in a fireproof safe (though this won't guarantee that they will survive). Too many people on this list think the best solution to security problems is to ignore them and be quiet about them and hope that the word doesn't get out. That is wrong; it never worked and it's even less likely to in the future. -- Joe Buck | Entropic Processing, Inc. UUCP: {ucbvax,ihnp4}!dual!epicen!jbuck | 10011 N. Foothill Blvd. ARPA: dual!epicen!jbuck@BERKELEY.ARPA | Cupertino, CA 95014