Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!labrea!decwrl!pyramid!prls!mips!dce
From: dce@mips.UUCP (David Elliott)
Newsgroups: comp.sources.d
Subject: kermit lock files - setuid/setgid security holes
Message-ID: <605@quacky.UUCP>
Date: Wed, 19-Aug-87 11:04:16 EDT
Article-I.D.: quacky.605
Posted: Wed Aug 19 11:04:16 1987
Date-Received: Sat, 22-Aug-87 02:36:03 EDT
Distribution: world
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 40


I've had a number of responses to this problem, but no really
perfect solution.

The main theme seems to be "make kermit setuid uucp or setgid
daemon", which is not a good idea, folks. Think about it: if
kermit is setuid uucp, it allows users to read files owned by
uucp, like mail in /usr/spool/uucp/*. Making it setgid daemon
is not much better. This also affects file creation.

Now, tip goes to great lengths to fix this problem by swapping
the real and effective userids. The idea is that system calls
(with the exception of access()) use the effective userid, and
that the setreuid() system call can be used to swap these.

Thus, when the lock file is being created, the effective userid
is that of uucp and the real userid is (for example) that of dce.
Afterwards, these are swapped so that the effective userid is
that of dce, so no extra permissions are given. When the lock is
removed, the permissions are swapped so that the effective userid
is that of uucp.

Also, shell escapes must be done within a fork so that the
effective and real userids can be set to that of the original
user.

Other folks suggested making /usr/spool/locks publicly writable,
which is fine, except that it appears that either tip or uucp
is setting the port permissions to

	crw-r----- uucp

even after I set the permissions otherwise, so the problem isn't
just with the locks.

Since nobody has any fixes, I'll do the work myself and post
the changes.

-- 
David Elliott		{decvax,ucbvax,ihnp4}!decwrl!mips!dce