[ewg] Allowing ib dignostics to be run without being logged in as root.

[Doug Ledford]

On 05/25/2010 07:21 PM, Woodruff, Robert J wrote:
> Hal wrote,  
> 
>> If you really want any user to do this, is changing umad permissions
>> sufficient ? This is less of a security hole than setuid but does open
>> things up for malicious users.
> 
>> -- Hal
> 
> I wanted to avoid doing this as it would allow some malicious user to 
> just open /dev/umad and send random mads and cause big problems with the fabric.
> 
> I was thinking that if the applications like perfquery are "trusted"
> to not allow someone to do anything malicious, then having them 
> run as setuid root would not open a security hole ?
> 
> sudo sounds like if would allow them to run any command as root ID,
> which I think is a larger security hole than just setting the one
> or few trusted applications to setuid root. But then, I am not a 
> security expert so I may not know all of the possible issues with
> setting a command to setuid root.

(This may sound a bit like a lecture, but you indicated you didn't know
the implications of setting a program set uid root, so this is intended
to shed some light on the sorts of things involved in such a decision)

The problem with setting *any* command to setuid root is not whether or
not the command is supposed to do safe things, but whether or not the
command can be tricked (either itself or any of the libraries it is
linked against) into doing something unintended.  From that standpoint,
you have to examine every single possible area of user input into the
command and then determine whether or not malicious input can cause
things to go awry.  To use a fictitious, made up problem from the
perfquery.c code:

The user supplies the local port number to use on the command line, the
program uses strtoul() on the argument to convert it to an unsigned
long, but it does nothing to check the range of the port.  So far, this
is actual stuff from the program.  Now, for the sake of argument, let's
make up a nice, easy exploit ;-)

Assume the port is passed into a listen call at some point.  Let's also
assume that at some point there was a check in the application to make
sure the port was > 1024.  Then let's assume that the glibc
implementation of the listen call masked the int to just the valid port
range.  A malicious user could then pass in a number > 65536 to pass the
application's built in check for a port > 1024, but then when glibc
masked off to just the valid port range (0-65535), a properly
constructed int would mask down to something inside the reserved port
range of the TCP namespace (0-1023).  As long as the application is not
suid, no big deal because this trick would just result in the kernel
telling the application it couldn't listen on a port < 1024 as those are
reserved.  Once you make the application suid though, it could silently
use this trick to listen on a reserved port.  Of course, what you *do*
with that is still up in the air, but this highlights why making *any*
app suid root is a security risk.  It's not what the app is supposed to
do that matters, it's how a malicious user can trick the app into doing
something it was never intended to do that matters.  And those tricks
can be very non-obvious to casual inspection.  So, setting something to
suid root should be an absolute last resort thing.

Normally, you only do so after performing a security audit of the
application.  But a security audit doesn't guarantee an application is
100% exploit free.  Really, an audit just provides a relative level of
assurance that the app is safe to make suid root.  The level of
confidence is directly related to the level of expertise of the auditor
as well as the care taken by the auditor in this particular audit, and
it is inversely proportional to the complexity of the code.  So, to be
as safe as possible, you write your program to be as simple as possible,
to do only what it absolutely must suid root, and have the best auditor
audit it.


-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20100619/f18f22ac/attachment.sig>