aburt@isis.UUCP (Andrew Burt) (10/27/88)
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."
neil@zardoz.UUCP (Neil Gorsuch) (10/28/88)
In article <2347@isis.UUCP> aburt@isis.UUCP (Andrew Burt) writes: > ... >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 sent e-mail to Andrew Burt on October 13 expressing an interest in hosting a new new security mailing list. (Might have been swallowed, though :<) ). On October 23, I posted an offer to host the list on news.sysadmin. Today I recieved e-mail from Andrew burt and received this posting on the net. In all fairness, since I volunteered to start the list up again before Andrew Burt offered to do the same, I believe that the list should reside on zardoz and that I should be the new administrator. And in point of fact, a new mailing list with over 30 new members in the first 4 days IS IN PLACE and IS OPERATING on zardoz. Therefore, I call for a vote, in this group or by e-mail, about who should be the new administrator. The choice is up to you. Neil Gorsuch neil@cpd.com !uunet!ccicpg!zardoz!neil (714)547-3000
jbayer@ispi.UUCP (id for use with uunet/usenet) (10/30/88)
In article <31190@zardoz.UUCP>, neil@zardoz.UUCP (Neil Gorsuch) writes: . In article <2347@isis.UUCP> aburt@isis.UUCP (Andrew Burt) writes: . > ... . >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 sent e-mail to Andrew Burt on October 13 expressing an interest in hosting . a new new security mailing list. (Might have been swallowed, though :<) ). . On October 23, I posted an offer to host the list on news.sysadmin. . Today I recieved e-mail from Andrew burt and received this posting on the net. . In all fairness, since I volunteered to start the list up again . before Andrew Burt offered to do the same, I believe that the list should . reside on zardoz and that I should be the new administrator. And in point . of fact, a new mailing list with over 30 new members in the first 4 days . IS IN PLACE and IS OPERATING on zardoz. Therefore, I call for a vote, . in this group or by e-mail, about who should be the new administrator. . The choice is up to you. I would suggest that these two people should get together and attempt to to a dual-hosting (if it is possible). Since there is such interest and volume it might be a good idea to split the list between both of them. An additional thought might be to start up a secondary mailing list, devoted to security for a user as opposed to security for a system. Jonathan Bayer Intelligent Software Products, Inc.
cosell@bbn.com (Bernie Cosell) (10/31/88)
In article <31190@zardoz.UUCP> neil@zardoz.UUCP (Neil Gorsuch) writes: } ..[confusion getting the security list restarted TWICE, first by Neil, then } by Andrew] }... I believe that the list should }reside on zardoz and that I should be the new administrator. And in point }of fact, a new mailing list with over 30 new members in the first 4 days }IS IN PLACE and IS OPERATING on zardoz. Therefore, I call for a vote, }in this group or by e-mail, about who should be the new administrator. }The choice is up to you. Two things: a) awfully hard for me (at least) to make any determination. As a member of the (old) list, I mostly only really care that it comes back to life, and what host it is on seems to be a fairly low-level procedural question. I understand the situation between you and Andrew, but perhaps you and he should just sort it out (via a phone call or something?) and tell us the answer. b) Any chance of your new list picking up the members of Andrew's version? For my part, I was the BBN contact for the old list and managed the local repeater for it (unix-security-bbn) and I'd just as soon have that come back to life (it is still sitting there ready-to-go in our alias database) rather than start a new round of setup. In any event, I *surely* don't want *two* security mailing lists, so I was going to hold off re-registering BBN (assuming I have to do so) until this all settles down. __ / ) Bernie Cosell /--< _ __ __ o _ BBN Sys & Tech, Cambridge, MA 02238 /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com
jc@heart-of-gold (John M Chambers) (11/11/88)
In article <31190@zardoz.UUCP>, neil@zardoz.UUCP (Neil Gorsuch) writes: > In article <2347@isis.UUCP> aburt@isis.UUCP (Andrew Burt) writes: > > ... > > .... Unless the membership wishes to > >vote me out after I get it going again, I would like to remain administrator > >of the list. > > In all fairness, since I volunteered to start the list up again > before Andrew Burt offered to do the same, I believe that the list should > reside on zardoz and that I should be the new administrator. Oh goody, a fight! It's mine! No, it's mine! A modest proposal: There seems to be sufficient interest in a security mailing list that people are talking about multiple sites that act as distribution centers, and it looks like we might end up with a rather deep heirarchy with lots of weak links. Instead, why don't we just create a security newsgroup, to be distributed only among these few distribution centers? This will decrease administrative headaches for everyone. It'll also make everyone feel like they're in charge. OK, I know, everyone's going to holler "Usenet isn't secure!" But is it really all that insecure? Note that I'm not suggesting creating a network-wide comp.security newsgroup. I'd suggest calling it just "security" with no dots. Then it is very easy to control its spread, easier than with a mailing list. The distribution sites just go into their ~news/lib/sys file and add ",security" to the selected neighbors, and ",!security" to the rest. If a site administrator needs to keep the newsgroup a secret to only a small group of people, they can use the technique of putting the ~news/spool/security directory into a "security" group, and giving it 750 permissions. I contend that this is isomorphic to a bunch of re-mailing lists, no more (and no less) insecure, and easier to manage. Of course, we might find we also need security.unix, security.vms, security.tcp-ip, security.ms-dos, and so on. But that's for later. Can anyone give me a good explanation as to why this would be worse than a complicated tree of mailing lists? It would certainly be easier to manage. Also, I'd like to see some real-world experience with the security problems in a distributed bulletin board. I mean, we're all worrying about security in a network environment, right? What better test vehicle could we use than the usenet package, which is already quite widely used and (semi-)understood? It may not surprise anyone that I have a hidden agenda in making this suggestion. There are a bunch of projects about (both military and commercial) that involve the creation of distributed messaging and conferencing software. I've been tossing out the suggestion that a multi-million-dollar development project would likely come up with something weaker (in both capabilities and security) than the existing usenet package, which has been widely tested for a decade now. I've suggested analyzing usenet for security problems, and modifying it to correct the problems, rather than "re-inventing the wheel". The usual response is to just ridicule the suggestion because usenet is used by academia so it's obviously totally insecure. But nobody has yet given me a convincing argument (insults aren't arguments; they are just insults) that I'm wrong. I'd like to find out if it'd work. And if not, why not, so that future developers can avoid making the same mistakes. Here's a big chance for all you usenet partisans out there to show what your package can do. Anyone wanna go for it? Or can someone give me a good explanation as to why I'm wrong? -- From: John Chambers <mitre-bedford.arpa!heart-of-gold!jc> From ...!linus!!heart-of-gold!jc (John Chambers) Phone 617/217-7780 [Send flames; they keep it cool in this lab :-]