ARCHIVE: Unix 'Security Mailing List' - Archives (1984 - 1987)
DOCUMENT: Unix 'Security Mailing List' #1 1984-12-18 (1 file, 1995 bytes)
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
Date: 18 Dec 1984 2252-MST (Tuesday) Subject: Security Mail List, # 1 Well, there seems to be some interest in the security mailing list. Thus far, about 50 people have asked to be included. There seem to be two outstanding questions remaining: how to validate the list, and how to distribute the input. The first position on both of these questions is to ignore them; security holes in Unix should be treated like any other bug and reported. As Doug Gwyn says, I am in favor of broadcasting information about UNIX problems, security or otherwise, as WIDELY as possible. Yank your dial-ins if you want security. This, strangely enough, is what I would also prefer; however, that is because I work in a rather benign environment (management enforced) and am only worried by outsiders trying to get in. I only suggested starting this list because the data I need is not forthcoming, due to flames from those on the net (primarily academic users, I reckon) who have an active fifth column. They, too, have their point. Craig Partridge writes: Bug reports of the form "it is possible to become root in 5 minutes under release X" must be sent to absolutely trustworthy people or many hosts will go "poof!" before the system administrator logs on in the morning... Assuming we have to have some security then, first: who gets the list? In my original message, I referred to root users only. Several poeple have pointed out that there are others who need the data; bonafide consultants, people doing security development work, and so on. Then there's the other side: with micros abounding on the net, anyone can be a root. Many people with their own machines also have access to large machines, whose owners might not appreciate them knowing how to mangle their system. I would like to propose that anyone can receive the list, but they must be recommended by a major node's root user. By major, I mean that the node has to be listed in the uucp map as a company or an educational institution. I will request the recommendation from the root myself, to preclude the kremvax problem (that's no doubt not foolproof either, but what the hell...). The solutions to the problem of how to distribute the data range from the ridiculous to the just-sub-sublime. Several think it is not worth the effort, since keys will have to be passed (and not leaked), uuencode may have to be used, and so on. Its undoubtedly a hassle. Rob Warnock suggests: On the other hand, we could always use the netnews distribution to send encrypted news, no? Distribute the keys verbally over the phone, and post the messages openly to the net. (I'm not sure whether or not I'm joking... !?!?) If we do encrypt, then how? Crypt(1) has been pretty well killed by the BSTJ article. There are DES and Lucifer algorithms around; DES might even be exportable (out of country, that is). And then there's keys. As chuqui says: Encrypting probably won't be worth it. Unless you are willing to set up a crypt password for each person serparately (wanna crypt 70 copies of each message? *grin*) then you'll have a single password that will rapidly become public knowledge (one person knows a secret, two people know a rumor, three people send out abstracts) and creating useless hassles. I again lean toward the lazy side: let the "security" inherant in mail itself protect the data. As a practical matter, just how secure is mail w.r.t. casual snooping by the non-super user? Let me know what you think, especially on those cases that you feel would be altogether too loose or too restrictive. I'll try to make some kind of decision over the holidays. Speaking of which, be merry. Lyle McElhaney ...denelcor!lmc --------------------------------------------
END OF DOCUMENT
|ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved.|