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