From owner-freebsd-security Sun Aug 25 20:31:48 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA14014 for security-outgoing; Sun, 25 Aug 1996 20:31:48 -0700 (PDT) Received: from bsd7.cs.sunysb.edu (bsd7.cs.sunysb.edu [130.245.1.197]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA14008 for ; Sun, 25 Aug 1996 20:31:41 -0700 (PDT) Received: (from uucp@localhost) by bsd7.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id XAA14256 for security@freebsd.org; Sun, 25 Aug 1996 23:31:38 -0400 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.7.5/8.6.9) id XAA12903; Sun, 25 Aug 1996 23:30:42 -0400 (EDT) Date: Sun, 25 Aug 1996 23:30:42 -0400 (EDT) From: Gene Stark Message-Id: <199608260330.XAA12903@starkhome.cs.sunysb.edu> To: security@freebsd.org Subject: Vulnerability in the Xt library (fwd) References: <4vqqpl$bn8@starkhome.cs.sunysb.edu> Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is the worst one yet for me. A crazy idea occurred to me, what do other people think? Why not nip all this stuff in the bud by changing the semantics of exec() so that setuid privilege is turned off unless the program has previously executed a (new) system call that says "I really want setuid privileges to be passed to my children." Of course, this would be nonstandard, but it would have the nice property that since no existing program calls this system call (it doesn't exist yet) no further exploits of this type would be possible with existing software. Calls to this new system call could then be introduced carefully into existing software, right at the point where an exec that *has* to preserve setuid privilege is performed. I would hazard a guess (flame me if I'm wrong) that most setuid programs don't need to exec other stuff, so this type of change would not break as many things as you might think at first. - Gene Stark