[comp.sources.d] kermit lock files - setuid/setgid security holes

dce@mips.UUCP (David Elliott) (08/19/87)

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

daveb@geac.UUCP (Brown) (08/20/87)

In article <605@quacky.UUCP> dce@mips.UUCP (David Elliott) writes:
>The main theme seems to be "make kermit setuid uucp or setgid
>daemon", which is not a good idea, folks. 

  Oops, I wasn't thinking when I sugested that!
  I meant to say make a program executable by the Kermit _group_
but owned by root create/delete the lock files.  Then you make it 
clean up any existing locks set by the same user (on the same port?),
so if you crash out of Kermy your next try cleans up the dangling
lock.

 --dave (put brain in gear befor engaging mouth) colier-brown


-- 
 David Collier-Brown.                 {mnetor|yetti|utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

sob@watson.tmc.edu (Stan Barber) (08/21/87)

I should point out that C-Kermit(041) does handle lock files correctly
under BSD4.3 with the 4.3UUCP locking structure. This creates a lock
directory (/usr/spool/uucp/LCK) that is publically writable and each
program (except kermit) using the locking protocol is smart enough to test for
dead locks (coming from programs that aborted and did not remove its
lock).

Stan