Path: utzoo!attcan!uunet!ncrlnk!ncrcae!ece-csc!mcnc!xanth!nic.MR.NET!tank!ncar!boulder!pikes!udenva!isis!aburt From: aburt@isis.UUCP (Andrew Burt) Newsgroups: news.sysadmin Subject: Security list awakes Message-ID: <2347@isis.UUCP> Date: 27 Oct 88 04:38:30 GMT Organization: University of Denver, Math/CS Lines: 152 I apologize profusely for (a) not having read news.sysadmin and (b) keeping the list dormant for so long. Regarding (b), I have consistently felt that significant positive events were "Just around the corner" from happening that consistently failed to happen or took far longer than expected, and that significant negative events would cease to happen -- with respect to local network connectivity, problems with the administrative structure of the list, availability of free time on my part, etc. I've felt pangs of guilt about not getting the list back sooner and relying on others to come through, but what I've decided is that I will take a pessimistic approach hereafter, make a few changes to the way the list functions to reduce the time it takes, and get it going again immediately. I appreciate the offers of assistance in the effort to keep the security mailing list alive, both by way of hosting the address list and by taking on the role of administrator. Unless the membership wishes to vote me out after I get it going again, I would like to remain administrator of the list. I am sending out messages concurrent with this posting to site admins of sites which can most assist the list. I have recently decided, however, that radical changes are called for, primarily caused by changes in the structure of the internet such as rapid growth of number of nodes and the use of domain names. These problem are both security related and administrative. For example, it used to be fairly trivial to detect the numerous workstation "root"s attempting to join, where such may well be undergraduate students... Other problems faced are high volume of requests to join that are sent with only partial or incorrect information, users who request back issues because of undelivered messages, and whose addresses suddenly go defunct without warning (e.g., leaving their company), and performing multiple background checks on the same individual because the sites I chose to contact to validate their character never reply, reply with insufficient information, etc. For the first problem, which is by far the biggest threat to the integrity of the list, I believe the solution lies in only accepting "very large" sites and letting them re-direct mail internally to appropriate systems and users. With the advent of uunet, it is no longer feasible to ask a prospective member's uucp neighbor (e.g., uunet) about their character, since it is likely nobody at uunet would be able to vouch for them. Similarly, sites on the internet used to be fairly easy to validate because of the relative difficulty involved in becoming an arpa/bitnet/etc. node. Now someone with a home machine can look like a site with thousands of users. Considering that the larger the list is the less secure it becomes, I feel it will be prudent to strengthen the nature of the tests applied to join the list. I've thought about many changes the list could undergo, and I think the following are appropriate: To make administration easier: - To join, a member must send answers to the usual questions (name, address of contact person, etc.) in a specific -- machine parseable -- format, to an address on my machine (isis), which will have a program gather all the answers in said format for display to the administrator. Previously I've had to retype every member's name, address, etc. over again when admitting them to the list, quite a chore given the number of requests to join I get. Particularly annoying when information is lacking. If a request is incomplete or not in correct form the front end program will (attempt to) bounce it back; regardless, I will ignore it. - To get the official form, a prospective member will send mail to a different address on this machine, which will do no more than send out a description of (and a shell script to help fill out) the official format of a "join request". - I will not mail out back issues, but will instead request that users obtain the material from another member of the list. (Archives, however, will be available as before.) - Likewise, bounced mail will be dropped on the floor. I tried to remail every bounced message before, and it was very time consuming. - The list will be stored on several sites rather than on just isis. I will maintain a master list, but will parcel out lists to distribution points around the net. When a member fills out the official join request, one question will be which distribution point they want to receive mail from. (For me to try to decide would lead to numerous poor choices.) The applicant will also be responsible for providing correct paths from isis to their machine, and from their chosen distribution point to their machine. Security enhancements: - The join-request form will be mailed to root on the machine of the member who asked for the form. Previously the root of the applicant's machine would get a note asking whether the applicant was acceptable in their opinion. The problem that root's mail might be readable does not go away, but the step of asking root if the person is ok is no longer needed. Many list members complained about this. A related issue is that the form used for roots to verify a site was the same for all roots. Thus, if a user on machine X applies and can read root's mail on X, he could forge not only X!root's reply, but those of uucp neighbors who may also have been asked to vouch for X!user. Now the form for ok'ing X!user will never be seen on X. - The applicant will be asked to provide site names of large sites that will validate their character. Previously I've had to guess, not always correctly, who a site talked to. This saves me guessing, and also forces the applicant to come up with someone who will vouch for their character. I will then send a background check request to those sites (taking the paths right out of the join-request message), unless I feel the sites chosen are not trustworthy themselves. This addresses the issue of internet sites, whose users grumbled that there was no "uucp neighbor" who could vouch for them. - The list will always be mailed to address "seclist" on a member's machine. If a member is unable to create an alias locally -- or create a dummy user -- then they are clearly not membership material. (And mart mailers are now widely available enough that aliases need not be restricted to BSD machines.) - For internet sites, I will only send to one host at a given site. E.g., for *.foo.edu I would only send to one specific address. Any other users at foo would have to join the site list. - To insure mail is being received by sites, and that circumstances have not changed such that a site that becomes untrustworthy remains on the list, I will ask for re-registration periodically (no more than once a year). Give me a few days to coordinate sites to handle redistribution, then I will announce (to news.sysadmin and to the old mailing list members) the new procedures for signing up. -- Andrew Burt ncar!isis!aburt "Now go away or I shall taunt you a second time."