[ofa-general] Allowing end-users to query for fabric information

[Mike Heinz]

I'm aware there are several approaches to solving the problem. My
"fixation" is in making sure I understand why there is an apparent
security hole in the fabric management.

See, my "root" problem here is that y'all are telling me that if a user
gains root access to a single node on the fabric, they can use that node
to undermine the entire fabric.

--
Michael Heinz
Principal Engineer, Qlogic Corporation
King of Prussia, Pennsylvania

-----Original Message-----
From: Roland Dreier [mailto:rdreier at cisco.com] 
Sent: Wednesday, October 08, 2008 2:27 PM
To: Mike Heinz
Cc: Hal Rosenstock; general at lists.openfabrics.org
Subject: Re: [ofa-general] Allowing end-users to query for fabric
information

 > Well, all that I want the tool to do is collect information; I don't
> want users to be able to modify the SM settings - but you have to
admit,  > it could be useful to someone trying to tune their fabric to
be able  > (for example) get a report on the length of the paths between
any two  > nodes.

I can think of several ways to implement this that do not require making
the umad device files accessible to all users.  This really is not
complicated stuff, and I'm not sure why you're so fixated on giving raw
access to MADs to all users.  You could:

 - implement a kernel-level service that exposes a high-level set of
   safe queries, which can be made available to all users.

 - you could install your tools as SUID binaries that allow ordinary
   users to run them with the elevated privileged required for MAD
   access; of course this requires some care to be taken in how you
   implement the query tools, so that they don't allow arbitrary
   privilege escalation due to security bugs.

 - you could create a new group, eg "ibadmin" and have the umad files
   owned by this group with permissions 0660.  Then users that need
   access to this tool could be added to the ibadmin group.

 > So, the critical issue is that some SMs don't implement the M-Key  >
properly? 

Or administrators have not enabled M_Keys with their SM config.  Or they
don't want to open the possibility of a user DOS-ing the SM (via a flood
of MADs sent through the raw access file) and waiting for the M_Key
timeout to take over the fabric.  Or...

The way I look at the permissions of the umad files is that it is just
common sense to restrict unfiltered access to sending and receiving
MADs.  This is analogous to restrictions on binding to ports below 1024
or sniffing packets that traditionally exist.

 - R.