From owner-freebsd-current Tue Sep 2 16:33:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA04452 for current-outgoing; Tue, 2 Sep 1997 16:33:27 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04437 for ; Tue, 2 Sep 1997 16:33:08 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id BAA22251; Wed, 3 Sep 1997 01:32:50 +0200 (MET DST) Date: Wed, 3 Sep 1997 01:32:50 +0200 (MET DST) Message-Id: <199709022332.BAA22251@bitbox.follo.net> From: Eivind Eklund To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= CC: perhaps@yes.no, current@FreeBSD.ORG In-reply-to: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?='s message of Tue, 2 Sep 1997 18:59:51 +0400 (MSD) Subject: Re: games uid->gid does too much damage! Who ever got this idea and why? References: Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > An addition to patches you work now: > /usr/games/cfscores and /usr/games/snscore should be moved out of DM > (remove HIDEGAME since they are not a games). > It assumes that score files itself remains public-readable, of course. > > BTW, better way to be protected is not make binary setuid/gid at all if > possible, more better then revoke setuid/gid early at startup since > worms can be found in startup code. Bloating non setuid/gid binary with > revoke code is not needed and not helps for startup worms in any case. OK. Due to the problems with the present patch, I've been thinking of an alternative, for which I'm awaiting feedback from Theo deRaadt (ways to break this scheme also requested from all -current readers): (1) Change dm back to setuid _and_ setgid games. (2) Set dm schg (3) Set mode on /usr/games/hide to root.games 550 (4) Change all games to be owned by bin.bin (or preferably root.bin, except that is against policy) (5) Make all hidegames revoke setuid/setgid as soon as possible (which I think they already do) This should (if I'm not missing anything) stop the possibility of anybody doing overwriting any executables with a games exploit. Eivind.