From owner-freebsd-security Thu Dec 23 17:37:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 08AD515167 for ; Thu, 23 Dec 1999 17:37:13 -0800 (PST) (envelope-from noslenj@swbell.net) Received: from swbell.net ([207.193.26.67]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with ESMTP id <0FN80086A1TY38@mta4.rcsntx.swbell.net> for security@freebsd.org; Thu, 23 Dec 1999 19:37:12 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by swbell.net (8.9.3/8.9.3) with ESMTP id TAA01063 for ; Thu, 23 Dec 1999 19:34:10 -0600 (CST envelope-from noslenj@swbell.net) Date: Thu, 23 Dec 1999 19:34:10 -0600 (CST) From: Jay Nelson Subject: setuid and cmdtool? To: security@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My question is about making the xview based cmdtool run safely suid root so that utmp is updated. As it is, cmdtool does not have the authority to write to utmp. cmdtool is more of a wrapper for xview -- all the terminal functions come from the xview libraries. To make it work, it looks like I would have to run suid root, but it would take changes to both cmdtool and the xview library to restrict access to the real user id. Since it hasn't been done, I'm probably overlooking something obvious so I'm looking for some one to show me the problems. If I seteuid root just before the utmp update and setreuid just after the update in xview, any risk seems minimal since any calling function without root access couldn't execute seteuid to root if the calling program were not suid root. If I run cmdtool suid root, I gain the ability to switch to root in xview for the utmp update, but would have to set the effective uid to the real id as the first instruction in cmdtool. It looks like this would get utmp updated without unreasonable exposure. Is this reasonable? What holes would I open up? On the other hand, is there any practical value to logging pseudo terminals to utmp? Thanks -- Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message