[ofa-general] OpenSM Console Ideas?

[Timothy A. Meier]

Hi Hal,
   I haven't had very much feedback yet.  Do you have any idea how many people
use the console?

Hal Rosenstock wrote:
> Hi Tim,
> 
> On Thu, 2008-02-21 at 16:27 -0800, Timothy A. Meier wrote:
>> LLNL uses the remote console feature in OpenSM.  We have a need to secure
>> this remote connection with authentication/authorization and encryption
>> (specifically PAM and OpenSSL).  I have a working prototype, and would
>> like to formalize it and share/include this with OpenSM.
>>
>> Before I go down this path too far, I would like to solicit ideas from
>> others who use the console.
>>
>> Currently, the console can be used in local, loopback, or remote modes.
>> If security is added, should it replace other modes, or be an additional mode?
> 
> IMO the old modes should be preserved and I would view
> authentication/authorization and encryption as an orthogonal dimension
> to be supported with any of those modes.
> 
This was my initial instinct as well.  Honestly, however, once we have
a secure connection, we will probably use it exclusively.  I suppose the
local console would also be necessary.  I can preserve all modes.

>> The intention is to use PAM for the AA framework, and OpenSSL for secure
>> sockets.  Are there any serious objections to this implementation plan?
> 
> Is the license compatible with OpenFabrics ?
>
Well I am not a lawyer, but I believe that it is.  OpenSSL has a dual license,
both are BSD-style open source licenses (one for the toolkit, one for openssl).
An alternate to OpenSSL is GNU TLS.  GNU TLS is not as widely used, and has
the GNU Lesser GPL which is supposed to be extremely lax.

The PAM libraries are included with most linux distros, (RH, Debian, etc.) and
have BSD style and GNU GPL licenses.

>> The console feature has always been a configuration/command line option,
>> but should the secure console be conditionally compiled/linked as well?
>> (eliminate dependency on the PAM and OpenSSL libs, pam, pam_misc, cryto, ssl).
> 
> This might depend on the licensing. Also, on one hand, it would be nice
> to minimize the build options, but for those where space is an issue,
> the separate configurability of this would be useful. (Not knowing the
> additional size of this but it sounds like it will be large enough to
> not make this a mandatory requirement of the console).
> 
> -- Hal
>
Agreed.  Should it NOT include the security stuff into the build, by default?
And the Console be disabled by default, and if enabled, default to "local"?

>> The secure console would require a relatively primitive client application,
>> which I will probably package under opensm, just like osmtest.  Make sense?
>>
>> Do you have any other ideas or suggestions for the remote console?
>>
> 


-- 
Timothy A. Meier
Computer Scientist
ICCD/High Performance Computing
925.422.3341
meier3 at llnl.gov