From huntting@hunkular.glarp.com  Thu Jun 21 21:41:05 2001
Return-Path: <huntting@hunkular.glarp.com>
Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251])
	by hub.freebsd.org (Postfix) with ESMTP id E7CCB37B411
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 21 Jun 2001 21:41:04 -0700 (PDT)
	(envelope-from huntting@hunkular.glarp.com)
Received: (from huntting@localhost)
	by hunkular.glarp.com (8.11.3/8.11.3) id f5M4f3i73166;
	Thu, 21 Jun 2001 22:41:03 -0600 (MDT)
	(envelope-from huntting)
Message-Id: <200106220441.f5M4f3i73166@hunkular.glarp.com>
Date: Thu, 21 Jun 2001 22:41:03 -0600 (MDT)
From: Brad Huntting <huntting@glarp.com>
Reply-To: huntting@glarp.com
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: rtprio/idprio setuid problems
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         28333
>Category:       bin
>Synopsis:       rtprio/idprio setuid problems
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jun 21 21:50:00 PDT 2001
>Closed-Date:    Sat May 12 09:47:01 GMT 2007
>Last-Modified:  Sat May 12 09:47:01 GMT 2007
>Originator:     Brad Huntting
>Release:        4.3 & 5.0
>Organization:
>Environment:
System: FreeBSD hunkular.glarp.com 4.3-STABLE FreeBSD 4.3-STABLE #0: Tue Jun 19 21:59:34 MDT 2001 root@hunkular.glarp.com:/usr/src/sys/compile/HUNKULAR i386


	
>Description:
	On some (but by no means all) systems it is desireable to
	allow non-root users the ability to start realtime processes.
	The obvious way to allow this is to "chmod u+s /usr/sbin/rtprio".
	Unfortunatly, this causes all programs started with rtprio
	(and idprio) to run as root.  The included patch adds a
	line to reset the euid before exec()ing the program.

	Note:  I am NOT advocating that rtprio should be installed
	setuid-root by default!  However, if the sysadmin wants to
	allow non-root users this privledge, then making a setuid-root
	program (perhaps executable by only one group) is the "unix
	way".

	This patch allows non-root users to change the priority of
	any process.  If this is not desireable, then another
	setuid(getuid()) should be added after the "case 1:" line
	as well.

>How-To-Repeat:
	$ id
	uid=1967(huntting) gid=0(wheel) groups=0(wheel)
	$ sudo chmod u+s /usr/sbin/rtprio
	$ /usr/sbin/rtprio 5 id
	uid=1967(huntting) euid=0(root) gid=0(wheel) groups=0(wheel)
			   ^^^^^^^^^^^^
			   Anoying side effect


>Fix:

--- rtprio.c.orig	Thu Jan 25 06:25:41 2001
+++ rtprio.c	Thu Jun 21 22:09:26 2001
@@ -119,6 +119,7 @@
 		if (rtprio(RTP_SET, proc, &rtp) != 0)
 			err(1, "%s", argv[0]);
 
+		setuid(getuid());		/* In case we are set-uid */
 		if (proc == 0) {
 			execvp(argv[2], &argv[2]);
 			err(1, "%s", argv[2]);
>Release-Note:
>Audit-Trail:

From: Kris Kennaway <kris@obsecurity.org>
To: Brad Huntting <huntting@glarp.com>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/28333: rtprio/idprio setuid problems
Date: Sun, 8 Jul 2001 15:15:12 -0700

 --nmemrqcdn5VTmUEE
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, Jun 21, 2001 at 10:41:03PM -0600, Brad Huntting wrote:
 
 > 	On some (but by no means all) systems it is desireable to
 > 	allow non-root users the ability to start realtime processes.
 
 The same can be same about almost any program which requires superuser
 privileges, not just rtprio/idprio.
 
 > 	The obvious way to allow this is to "chmod u+s /usr/sbin/rtprio".
 > 	Unfortunatly, this causes all programs started with rtprio
 > 	(and idprio) to run as root.  The included patch adds a
 > 	line to reset the euid before exec()ing the program.
 >=20
 > 	Note:  I am NOT advocating that rtprio should be installed
 > 	setuid-root by default!  However, if the sysadmin wants to
 > 	allow non-root users this privledge, then making a setuid-root
 > 	program (perhaps executable by only one group) is the "unix
 > 	way".
 
 No, the UNIX way is to use something a tool like sudo (in the ports
 collection) which lets the admin manage which users get to execute
 which commands with privilege.  Adding uid-management code to all
 sorts of non-privileged binaries just in case someone misguidedly
 makes it setuid is the wrong solution.
 
 Kris
 
 --nmemrqcdn5VTmUEE
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.6 (FreeBSD)
 Comment: For info see http://www.gnupg.org
 
 iD8DBQE7SNtuWry0BWjoQKURAhxZAKDfbdX59sxcaU7GyDEW810q9sFuTACgoaWx
 f+oz8/IdBuSHmBhHAKyrIJI=
 =bZwS
 -----END PGP SIGNATURE-----
 
 --nmemrqcdn5VTmUEE--

From: Brad Huntting <huntting@glarp.com>
To: Kris Kennaway <kris@obsecurity.org>
Cc: Brad Huntting <huntting@glarp.com>,
	FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/28333: rtprio/idprio setuid problems 
Date: Sun, 08 Jul 2001 17:06:29 -0600

 >> 	On some (but by no means all) systems it is desireable to
 >> 	allow non-root users the ability to start realtime processes.
 
 > The same can be same about almost any program which requires superuser
 > privileges, not just rtprio/idprio.
 
 >> 	The obvious way to allow this is to "chmod u+s /usr/sbin/rtprio".
 >> 	Unfortunatly, this causes all programs started with rtprio
 >> 	(and idprio) to run as root.  The included patch adds a
 >> 	line to reset the euid before exec()ing the program.
 >>=20
 >> 	Note:  I am NOT advocating that rtprio should be installed
 >> 	setuid-root by default!  However, if the sysadmin wants to
 >> 	allow non-root users this privledge, then making a setuid-root
 >> 	program (perhaps executable by only one group) is the "unix
 >> 	way".
 
 > No, the UNIX way is to use something a tool like sudo (in the ports
 > collection) which lets the admin manage which users get to execute
 > which commands with privilege.  Adding uid-management code to all
 > sorts of non-privileged binaries just in case someone misguidedly
 > makes it setuid is the wrong solution.
 
 Granted, for programs like renice, chown, etc, sudo is ideal.  But
 chroot, {id,rt}prio, and nice are different because, not only do
 they perform a prevledged operation, they exec() a new program
 afterward.
 
 A sudo like wrapper for these would need to grok the command line
 semantics of each utilities to be a viable alternative.  Even then,
 it would be a security risk, unless it provided some mechanism to
 insure that the command line semantics of nice (et al) stay in sync
 with this sudo-like program.  And once you've gone to all that
 trouble you might has well just make a special setuid version of
 nice (et al) that does uid management and is runable by ordinary
 users.  Once you've done that, you might as well call it "nice"
 (etc), because everyone already understands how "nice" works.
 
 Or did you have some other idea for a sudo like tool.
 
 
 thanx,
 brad

From: Kris Kennaway <kris@obsecurity.org>
To: Brad Huntting <huntting@glarp.com>
Cc: Kris Kennaway <kris@obsecurity.org>,
	FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/28333: rtprio/idprio setuid problems
Date: Sun, 8 Jul 2001 16:17:35 -0700

 --G4iJoqBmSsgzjUCe
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Sun, Jul 08, 2001 at 05:06:29PM -0600, Brad Huntting wrote:
 
 > > No, the UNIX way is to use something a tool like sudo (in the ports
 > > collection) which lets the admin manage which users get to execute
 > > which commands with privilege.  Adding uid-management code to all
 > > sorts of non-privileged binaries just in case someone misguidedly
 > > makes it setuid is the wrong solution.
 >=20
 > Granted, for programs like renice, chown, etc, sudo is ideal.  But
 > chroot, {id,rt}prio, and nice are different because, not only do
 > they perform a prevledged operation, they exec() a new program
 > afterward.
 >=20
 > A sudo like wrapper for these would need to grok the command line
 > semantics of each utilities to be a viable alternative.  Even then,
 > it would be a security risk, unless it provided some mechanism to
 > insure that the command line semantics of nice (et al) stay in sync
 > with this sudo-like program.  And once you've gone to all that
 > trouble you might has well just make a special setuid version of
 > nice (et al) that does uid management and is runable by ordinary
 > users.  Once you've done that, you might as well call it "nice"
 > (etc), because everyone already understands how "nice" works.
 >=20
 > Or did you have some other idea for a sudo like tool.
 
 Have you positively determined that sudo or another such existing tool
 can't be used to do what you want?
 
 Kris
 
 --G4iJoqBmSsgzjUCe
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.6 (FreeBSD)
 Comment: For info see http://www.gnupg.org
 
 iD8DBQE7SOntWry0BWjoQKURAsXgAKDj87FSsARhOlx6MOgqNzByoxxHMgCfcvLN
 0t3ukdVdm8IGa7Xc/1m2UMM=
 =4Am4
 -----END PGP SIGNATURE-----
 
 --G4iJoqBmSsgzjUCe--

From: Brad Huntting <huntting@glarp.com>
To: Kris Kennaway <kris@obsecurity.org>
Cc: Brad Huntting <huntting@glarp.com>,
	FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/28333: rtprio/idprio setuid problems 
Date: Sun, 08 Jul 2001 22:17:21 -0600

 > Have you positively determined that sudo or another such existing tool
 > can't be used to do what you want?
 
 After looking around, I think POSIX1e Capabilities are probably
 the best solution to this problem.  It comes with alot of security
 bagage, but it's probably the "right" way to solve which is
 essentially a fine-grain security issue.
 
 
 thanx,
 brad
State-Changed-From-To: open->closed 
State-Changed-By: pav 
State-Changed-When: Sat May 12 09:43:03 UTC 2007 
State-Changed-Why:  
Looks like there's agreement this can be solved better than by proposed patch 

http://www.freebsd.org/cgi/query-pr.cgi?pr=28333 
>Unformatted:
