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

2010-06-19 Thread Doug Ledford
On 05/26/2010 03:52 PM, rich...@informatix-sol.com wrote:
 It's better to be statically linked.

This is not the opinion of most people I know.  It used to be the norm
back in the day, but the truth of the matter is that when it comes to
system libraries, if an attacker has managed to compromise either a
system library or the dynamic linker, then the system is already lost
and the ability to compromise your program is moot.  If, on the other
hand, you have statically linked your program and then an exploit has
been found in the library you statically linked, now your program is
vulnerable even after the system shared library has been updated.

Having said that, I've seen packages from OFED developers that tend to
do multiple of the various bad security practices.  Things like
installing libraries in places like /usr/local or even in home
directories, or using rpath in programs to allow circumvention of system
installed shared libraries.  These are things that should *never* be
done on production software or systems and should be purged from any
software prior to release.

 However all setuid programs present
 a threat. The challenge as a security administrator is to assess and
 minimize the threat. Smaller programs where you can inspect and
 understand the program are more trustable than large complex programs.

This part is very true.

-- 
Doug Ledford dledf...@redhat.com
  GPG KeyID: CFBFF194
  http://people.redhat.com/dledford

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



signature.asc
Description: OpenPGP digital signature
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

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

2010-06-19 Thread 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 dledf...@redhat.com
  GPG KeyID: CFBFF194
  http://people.redhat.com/dledford

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



signature.asc
Description: OpenPGP digital signature
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

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

2010-06-02 Thread Roland Dreier
   $ cat /etc/udev/rules.d/80-ib-umad.rules
   KERNEL==umad*, NAME=infiniband/%k, MODE=0666

  It is not the same. Your propose to expose /dev/infiniband/umad device
  access to all world, which is obviously even more dangerous than SUIDing
  diagnostic programs.

Well, different threats.  Making umad files world-writable means anyone
can inject whatever MADs they want to into the fabric.  On the other
hand, if an arbitrary code execution security hole is found in a
diagnostic program, then having it SUID root means the hole becomes a
local root exploit.  It's hard to assess which is really more dangerous.
-- 
Roland Dreier rola...@cisco.com || For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-06-01 Thread Yevgeny Kliteynik
Hi Woody,

On 31-May-10 2:43 AM, Sasha Khapyorsky wrote:
 Hi Woody,

 On 13:51 Tue 25 May , Woodruff, Robert J wrote:

 Some people were asking me if it would be possible to
 allow some of the IB diagnostic tools to be run without
 requiring being logged in as root. Would there be
 any problem in changing the installation to set their
 permissions to setuid root to allow this, i.e.,

 chmod +s /usr/sbin/ibnetdiscover
 chmod +s /usr/sbin/ibaddr
 chmod +s /usr/sbin/smpquery
 chmod +s /usr/sbin/perfquery

 As many others I would also suggest to not make it (at least in default
 installation).

 However you can try to run diagnostic tools as non-root user by doing
 follow:

 1. create some dedicated group, let's say 'umad'.
 2. add dedicated users to be a members of this group
 3. chown root:umad /dev/infiniband/umad*
 4. chmod 0660 /dev/infiniband/umad*
 5. update ib related udev rules file to match above

 This is how device access is granted to users normally.

No need to mess with users/groups/owners.

Udev configuration rules are in the following directory:
   /etc/udev/rules.d

Infiniband-related rules are here:
   /etc/udev/rules.d/90-ib.rules

$ cat /etc/udev/rules.d/90-ib.rules
KERNEL==umad*, NAME=infiniband/%k
...

You need to allow other users to get access to umad* devices.
Don't modify the 90-ib.rules. Instead add a new file, something like
80-ib-umad.rules. The number in the beginning of the file (80) should
be lower than the number in the file with the rule that you want to
override (90):

$ cat /etc/udev/rules.d/80-ib-umad.rules
KERNEL==umad*, NAME=infiniband/%k, MODE=0666

Restart the driver and you're done.

-- Yevgeny

 Sasha
 ___
 ewg mailing list
 ewg@lists.openfabrics.org
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-06-01 Thread Sasha Khapyorsky
On 12:44 Tue 01 Jun , Yevgeny Kliteynik wrote:
 
 $ cat /etc/udev/rules.d/80-ib-umad.rules
 KERNEL==umad*, NAME=infiniband/%k, MODE=0666

It is not the same. Your propose to expose /dev/infiniband/umad device
access to all world, which is obviously even more dangerous than SUIDing
diagnostic programs.

Sasha
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-30 Thread Sasha Khapyorsky
Hi Woody,

On 13:51 Tue 25 May , Woodruff, Robert J wrote:
 
 Some people were asking me if it would be possible to 
 allow some of the IB diagnostic tools to be run without
 requiring being logged in as root. Would there be
 any problem in changing the installation to set their
 permissions to setuid root to allow this, i.e.,
 
 chmod +s /usr/sbin/ibnetdiscover
 chmod +s /usr/sbin/ibaddr
 chmod +s /usr/sbin/smpquery
 chmod +s /usr/sbin/perfquery

As many others I would also suggest to not make it (at least in default
installation).

However you can try to run diagnostic tools as non-root user by doing
follow:

1. create some dedicated group, let's say 'umad'.
2. add dedicated users to be a members of this group
3. chown root:umad /dev/infiniband/umad*
4. chmod 0660 /dev/infiniband/umad*
5. update ib related udev rules file to match above

This is how device access is granted to users normally.

Sasha
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-26 Thread Hal Rosenstock
On Tue, May 25, 2010 at 7:21 PM, Woodruff, Robert J
robert.j.woodr...@intel.com 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 ?

I don't know exactly how setuid programs are exploited to obtain
general root access but I've heard this.

 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.

sudo can be configured for specific commands to be allowed to specific users.

-- Hal


 woody


 ___
 ewg mailing list
 ewg@lists.openfabrics.org
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-26 Thread Woodruff, Robert J
Hal wrote,

sudo can be configured for specific commands to be allowed to specific users.

Then perhaps that is a safer way to do it, but it would put more work
on the system admin to set it up for people, but if setting the permissions
of the commands to setuid root opens up a security hole, we would not want
that.

Does anyone know if setting the permissions to setuid root does actually
open up a security hole ?

woody

 
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-26 Thread Informatix solutions
The issue is that it is entirely dependent on the security integrity of the
application with the setuid bit set.
If someone can insert code, or swap a dynamically linked library with their
own alternative, it becomes possible to have your own code executed as root.
The system is then completely compromised.

-Original Message-
From: ewg-boun...@lists.openfabrics.org
[mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Woodruff, Robert J
Sent: 26 May 2010 17:19
To: Hal Rosenstock
Cc: EWG
Subject: Re: [ewg] Allowing ib dignostics to be run without being logged in
as root.

Hal wrote,

sudo can be configured for specific commands to be allowed to specific
users.

Then perhaps that is a safer way to do it, but it would put more work
on the system admin to set it up for people, but if setting the permissions
of the commands to setuid root opens up a security hole, we would not want
that.

Does anyone know if setting the permissions to setuid root does actually
open up a security hole ?

woody

 
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-26 Thread Hal Rosenstock
On Wed, May 26, 2010 at 12:29 PM, Informatix solutions
rich...@informatix-sol.com wrote:
 The issue is that it is entirely dependent on the security integrity of the
 application with the setuid bit set.
 If someone can insert code, or swap a dynamically linked library with their
 own alternative, it becomes possible to have your own code executed as root.
 The system is then completely compromised.

The IB diags do use dynamically linked libs (libibmad and libibumad).

-- Hal


 -Original Message-
 From: ewg-boun...@lists.openfabrics.org
 [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Woodruff, Robert J
 Sent: 26 May 2010 17:19
 To: Hal Rosenstock
 Cc: EWG
 Subject: Re: [ewg] Allowing ib dignostics to be run without being logged in
 as root.

 Hal wrote,

sudo can be configured for specific commands to be allowed to specific
 users.

 Then perhaps that is a safer way to do it, but it would put more work
 on the system admin to set it up for people, but if setting the permissions
 of the commands to setuid root opens up a security hole, we would not want
 that.

 Does anyone know if setting the permissions to setuid root does actually
 open up a security hole ?

 woody


 ___
 ewg mailing list
 ewg@lists.openfabrics.org
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-26 Thread Woodruff, Robert J
If the application is statically linked and trusted, then,  is there no 
security issue ? 

-Original Message-
From: Informatix solutions [mailto:rich...@informatix-sol.com] 
Sent: Wednesday, May 26, 2010 9:30 AM
To: Woodruff, Robert J; 'Hal Rosenstock'
Cc: 'EWG'
Subject: RE: [ewg] Allowing ib dignostics to be run without being logged in as 
root.

The issue is that it is entirely dependent on the security integrity of the
application with the setuid bit set.
If someone can insert code, or swap a dynamically linked library with their
own alternative, it becomes possible to have your own code executed as root.
The system is then completely compromised.

-Original Message-
From: ewg-boun...@lists.openfabrics.org
[mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Woodruff, Robert J
Sent: 26 May 2010 17:19
To: Hal Rosenstock
Cc: EWG
Subject: Re: [ewg] Allowing ib dignostics to be run without being logged in
as root.

Hal wrote,

sudo can be configured for specific commands to be allowed to specific
users.

Then perhaps that is a safer way to do it, but it would put more work
on the system admin to set it up for people, but if setting the permissions
of the commands to setuid root opens up a security hole, we would not want
that.

Does anyone know if setting the permissions to setuid root does actually
open up a security hole ?

woody

 
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-26 Thread Justin Clift
On 05/27/2010 02:19 AM, Woodruff, Robert J wrote:
 Hal wrote,

 sudo can be configured for specific commands to be allowed to specific users.

 Then perhaps that is a safer way to do it, but it would put more work
 on the system admin to set it up for people, but if setting the permissions
 of the commands to setuid root opens up a security hole, we would not want
 that.

 From an experienced SysAdmin perspective, the less setuid/setgid 
programs there are on a system the better.  If a system could have them 
*all* removed, that would be great. :)

Security types generally don't like them either, regarding them as a 
point of weakness due to circumventing finer grained access controls 
(sudo, ACLs, RBAC, etc).  setuid/setgid binaries are also included (and 
queried) in *every* system audit.

Good security practise will generally change the binaries back to being 
non-setuid/non-setgid (ie normal perms) unless there's a Very Good 
Reason for them to be otherwise.

I have personally had to secure/harden many *nix systems over the years, 
plus write detailed technical best practice guides for multi-national 
corporates on how to do it on more than one occasion.  Last time was in 
roughly 2006, and setuid/setgid stuff was regarded as bad old practise 
at that time.  I'd expect it would be even less favoured now.


 Does anyone know if setting the permissions to setuid root does actually
 open up a security hole ?

Not directly.  It just creates lots of secondary hassles for SysAdmins, 
Security Admins, policy enforcement software, and monitoring software 
because it introduces another vector for attack.

People having a need for setuid or setgid root for these binaries can 
most definitely do it themselves as part of their roll out.

Not sure if that perspective helps, but you do seem to be asking. :)

Regards and best wishes,

Justin Clift


 woody


-- 
Salasaga  -  Open Source eLearning IDE
   http://www.salasaga.org
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-26 Thread Ira Weiny
To steer the conversation in a different direction.  Perhaps there is a need to 
have a second umad device file which allows only for Get operations?  I know 
this could be some work and I don't know if it could be completely done (I have 
not thought through all the details). [*]

I know there is some discussion on the interface for userspace apps and MAD's 
on the developers mailing list.  Is this a requirement we should look into 
more?  I know we have some need for this and now Woody has this need as well.

Thoughts?
Ira

[*] NOTE: I am not directly volunteering to do this work  ;-)  But I have been 
interested in changing the user level MAD libraries in the past so I think I 
could help.

On Wed, 26 May 2010 09:51:53 -0700
Justin Clift jus...@salasaga.org wrote:

 On 05/27/2010 02:19 AM, Woodruff, Robert J wrote:
  Hal wrote,
 
  sudo can be configured for specific commands to be allowed to specific 
  users.
 
  Then perhaps that is a safer way to do it, but it would put more work
  on the system admin to set it up for people, but if setting the permissions
  of the commands to setuid root opens up a security hole, we would not want
  that.
 
  From an experienced SysAdmin perspective, the less setuid/setgid 
 programs there are on a system the better.  If a system could have them 
 *all* removed, that would be great. :)
 
 Security types generally don't like them either, regarding them as a 
 point of weakness due to circumventing finer grained access controls 
 (sudo, ACLs, RBAC, etc).  setuid/setgid binaries are also included (and 
 queried) in *every* system audit.
 
 Good security practise will generally change the binaries back to being 
 non-setuid/non-setgid (ie normal perms) unless there's a Very Good 
 Reason for them to be otherwise.
 
 I have personally had to secure/harden many *nix systems over the years, 
 plus write detailed technical best practice guides for multi-national 
 corporates on how to do it on more than one occasion.  Last time was in 
 roughly 2006, and setuid/setgid stuff was regarded as bad old practise 
 at that time.  I'd expect it would be even less favoured now.
 
 
  Does anyone know if setting the permissions to setuid root does actually
  open up a security hole ?
 
 Not directly.  It just creates lots of secondary hassles for SysAdmins, 
 Security Admins, policy enforcement software, and monitoring software 
 because it introduces another vector for attack.
 
 People having a need for setuid or setgid root for these binaries can 
 most definitely do it themselves as part of their roll out.
 
 Not sure if that perspective helps, but you do seem to be asking. :)
 
 Regards and best wishes,
 
 Justin Clift
 
 
  woody
 
 
 -- 
 Salasaga  -  Open Source eLearning IDE
http://*www.*salasaga.org
 ___
 ewg mailing list
 ewg@lists.openfabrics.org
 http://*lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
 
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-25 Thread Woodruff, Robert J

Hi Sasha,

Some people were asking me if it would be possible to 
allow some of the IB diagnostic tools to be run without
requiring being logged in as root. Would there be
any problem in changing the installation to set their
permissions to setuid root to allow this, i.e.,

chmod +s /usr/sbin/ibnetdiscover
chmod +s /usr/sbin/ibaddr
chmod +s /usr/sbin/smpquery
chmod +s /usr/sbin/perfquery

woody
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-25 Thread Jon Forrest
On 5/25/2010 1:51 PM, Woodruff, Robert J wrote:

 Hi Sasha,

 Some people were asking me if it would be possible to
 allow some of the IB diagnostic tools to be run without
 requiring being logged in as root. Would there be
 any problem in changing the installation to set their
 permissions to setuid root to allow this, i.e.,

 chmod +s /usr/sbin/ibnetdiscover
 chmod +s /usr/sbin/ibaddr
 chmod +s /usr/sbin/smpquery
 chmod +s /usr/sbin/perfquery

As someone who's a novice to IB, but a long
time system manager, I'd say that this would be
a very risky thing to do. You'd better hope
that none of these program have any lurking
security holes.

Cordially,
-- 
Jon Forrest
Research Computing Support
College of Chemistry
173 Tan Hall
University of California Berkeley
Berkeley, CA
94720-1460
510-643-1032
jlforr...@berkeley.edu
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-25 Thread Hal Rosenstock
On Tue, May 25, 2010 at 4:51 PM, Woodruff, Robert J
robert.j.woodr...@intel.com wrote:

 Hi Sasha,

 Some people were asking me if it would be possible to
 allow some of the IB diagnostic tools to be run without
 requiring being logged in as root. Would there be
 any problem in changing the installation to set their
 permissions to setuid root to allow this, i.e.,

 chmod +s /usr/sbin/ibnetdiscover
 chmod +s /usr/sbin/ibaddr
 chmod +s /usr/sbin/smpquery
 chmod +s /usr/sbin/perfquery

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

 woody
 ___
 ewg mailing list
 ewg@lists.openfabrics.org
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg

___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-25 Thread Hal Rosenstock
On Tue, May 25, 2010 at 5:51 PM, Hal Rosenstock
hal.rosenst...@gmail.com wrote:
 On Tue, May 25, 2010 at 4:51 PM, Woodruff, Robert J
 robert.j.woodr...@intel.com wrote:

 Hi Sasha,

 Some people were asking me if it would be possible to
 allow some of the IB diagnostic tools to be run without
 requiring being logged in as root. Would there be
 any problem in changing the installation to set their
 permissions to setuid root to allow this, i.e.,

 chmod +s /usr/sbin/ibnetdiscover
 chmod +s /usr/sbin/ibaddr
 chmod +s /usr/sbin/smpquery
 chmod +s /usr/sbin/perfquery

 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.

IMO a better approach is to use sudo;

-- Hal


 -- Hal

 woody
 ___
 ewg mailing list
 ewg@lists.openfabrics.org
 http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg


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

2010-05-25 Thread Woodruff, Robert J
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.

woody


___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg