Bug 28333

Summary: rtprio/idprio setuid problems
Product: Base System Reporter: huntting
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description huntting 2001-06-22 05:50:00 UTC 
	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
Comment 1 Kris Kennaway 2001-07-08 23:15:12 UTC 
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.
> 
> 	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
Comment 2 huntting 2001-07-09 00:06:29 UTC 
>> 	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
Comment 3 Kris Kennaway 2001-07-09 00:17:35 UTC 
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.
> 
> 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.


Have you positively determined that sudo or another such existing tool
can't be used to do what you want?

Kris
Comment 4 huntting 2001-07-09 05:17:21 UTC 
> 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
Comment 5 Pav Lucistnik freebsd_committer freebsd_triage 2007-05-12 10:43:03 UTC 
State Changed
From-To: open->closed

Looks like there's agreement this can be solved better than by proposed patch