Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site illogica.UUCP Path: utzoo!linus!philabs!prls!amdimage!amdcad!amd!vecpyr!altos86!illogica!mickey From: mickey@illogica.UUCP (Michael Thompson) Newsgroups: net.unix-wizards Subject: Re: Need help on UUCP connection (4.2 <--> Ultrix) Message-ID: <135@illogica.UUCP> Date: Mon, 30-Sep-85 07:32:13 EDT Article-I.D.: illogica.135 Posted: Mon Sep 30 07:32:13 1985 Date-Received: Fri, 4-Oct-85 04:34:54 EDT References: <95@cholula.UUCP> <132@illogica.UUCP> <98@cholula.UUCP> <636@decuac.UUCP> Reply-To: mickey@.UUCP (Michael Thompson) Organization: Illogica Systems, Hayward, CA Lines: 77 Keywords: Ultrix UUCP security In article <636@decuac.UUCP> avolio@decuac.UUCP (Frederick M. Avolio) writes: >I article <98@cholula.UUCP>, tim@cholula.UUCP writes: >>In article <132@illogica.UUCP> mickey@illogica.UUCP (Michael Thompson)writes: >> => My bet is that your login name "UOurMachine" does not have a unique >> => UID. Some versions of UUCP (I've seen it in system V derivitives) do >> => a getuid() call and search linearly through the password file until >> => they find the *first* entry with a matching UID. The login name >> => associated with that UID is what is used to check against entries >> => in the USERFILE. >> >> Thanks Michael for the fix to the problem. Never even crossed my mind since >> 4.2 systems don't care about that. Apparently Ultrix UUCP is a mixture of >> SYS5 and 4.[23] UUCP. > >I am glad a fix was found, but based on the LOGFILE entries and our >experience the problem was not on the Ultrix system side. We talk to 13 >or so other sites -- Ultrix systems and non-Ultrix systems -- using the >Ultrix-32 UUCP. On our system as well as on some of the others, the uucp >login names are different but are all the same UID for different systems. >We have no problems. I suspect the problem -- based on the LOGFILE >entries -- was in the USERFILE of the other system. In fact, the problem >might be with a UUCP that didn't recognize system names of more than 6 >characters. > >Fred. Please keep in mind that as long as there *is* an entry in the remote USERFILE which corresponds to the first matching login name that is associated with the UID of the uucp account, then things will *appear* to work properly. But the implications of this can be illustrated thus: USERFILE: uucp, / pubuucp,somesys /usr/spool/uucppublic /etc/passwd: uucp:xCXK46Ju1PE1Q:4:4:UUCP account: ... pubuucp:rSL55Z9flVWhs:4:4:some other uucp account: ... Since both `pubuucp' and `uucp' have the same UID, the protections implied by entries in the USERFILE are *not properly enforced*. Since these certain versions of UUCP determine the login name by associating it with the first matching UID, any system logging into `pubuucp' would be givin access to / . A simple test to determine whether or not you have this type of UUCP or not is to remove, say, `pubuucp' from the remote USERFILE and see if you still have a UUCP link through that account. Or, you can remove the entry in the remote USERFILE which corresponds to `uucp' in my example. If you have this type of UUCP, all of your UUCP links which share UID's with `uucp' will fail. I don't know if this should be classified as a bug or not, but it certainly presents some security problems as well as other possible headaches - USERFILE: uucp, /usr/spool/uucppublic myuucp,mysys /usr/mickey /etc/passwd: uucp:xCXK46Ju1PE1Q:4:4:UUCP account: ... myuucp:rSL55Z9flVWhs:4:4:my own private UUCP account ... I could be banging my head against the wall trying to figure out why UUCP denies me access to my home directory even though I explicitly grant access in the USERFILE. mickey m. (Michael Thompson) {decwrl,ucbvax}!dual!vecpyr!altos86!illogica!mickey Brought to you by Super Global Mega Corp .com