Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!labrea!denali!karish
From: karish@denali.stanford.edu (Chuck Karish)
Newsgroups: comp.unix.wizards
Subject: Re: Who dat?
Message-ID: <23133@labrea.Stanford.EDU>
Date: 21 Jul 88 15:42:26 GMT
References: <199@stca77.stc.oz> <2310@rtech.rtech.com> <3789@rpp386.UUCP> <51@minya.UUCP>
Sender: news@labrea.Stanford.EDU
Reply-To: karish@denali.stanford.edu (Chuck Karish)
Organization: Mindcraft, Inc.
Lines: 26

In article <51@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>In article <3789@rpp386.UUCP>, jfh@rpp386.UUCP (John F. Haugh II) writes:
>> In article <2310@rtech.rtech.com> daveb@rtech.com (Dave Brower) writes:
>> >How can the server find out who the client is, in a spoof-proof and
>> >secure way?

>> have the client create a file with the suid and sgid bits set. 

>Let's see, what I do when you ask my process A to create this file is
>to have a program B sitting around that is setuid/setgid to whomever
>I want you to think A is; A would start up B as a subprocess, with the
>desired filename in argv[1]; B would create it.  How would you determine
>that A isn't this uid/gid combination?

This describes a situation in which the user has successfully created
a live Trojan horse.  It means that the user has cooperation from
the owner of the setuid file, or knew the super user password at some
time in the past.  In either case, security has been compromised in
ways that can't be detected under SysV.  An obvious administrative fix
is to scan periodically for setuid programs.



Chuck Karish	ARPA:	karish@denali.stanford.edu
		BITNET:	karish%denali@forsythe.stanford.edu
		UUCP:	{decvax,hplabs!hpda}!mindcrf!karish
		USPS:	1825 California St. #5   Mountain View, CA 94041