[ofa-general] Re: [PATCH] saquery: --smkey command line option

[Hal Rosenstock]

On Fri, 2008-05-23 at 15:34 +0300, Sasha Khapyorsky wrote:
> On 04:15 Fri 23 May     , Hal Rosenstock wrote:
> > 
> > > but now in IBA spec knowing a valid
> > > SM_Key is mandatory for privileged SA clients (which need to get whole
> > > list of MCMemberRecord, ServiceInfo, etc.).
> > 
> > It's a grey area.
> 
> I don't see this as "grey" - spec is very clear about this sort of SA
> restrictions.

It is not clear about the issues around the key proliferation. That is
what is grey at least to me but maybe I'm the only one (at least
speaking on this topic on this list).

> > The issue is what the privileged SA clients should be
> > used for.
> 
> It can be used for monitoring, SA DB sync/dump, debugging, etc..

All those uses are easily imagined but that's not what I meant by that
statement which was related to the key issue.

> > I think this use case allows much more common knowledge of the
> > management keys (in this case the SA key) as it will not just be the
> > network administrator using it and even if it were, the user would be
> > looking over his shoulder.
> 
> A network administrator is not a little kid :) and this option is
> optional. Following your logic we will need to disable root passwords
> typing too.

That's taking it too far. Root passwords are at least hidden when
typing.

> > That more common knowledge allows for a
> > malicious user to more easily compromise the subnet.
> 
> There is nothing which could prevent from a malicious user to put things
> in the code.

Of course not but it's one less hurdle to knock down.

> > A better approach to all these trust issues IMO is to use the OpenSM
> > console to support these types of operations.
> 
> OpenSM console is not protected even by SM_Key.

But can be protected by other weak access control currently and perhaps
more in the future. New commands which require trust can utilize SMKey
without it being specified (at least for OpenSM), no ?

> And what about diagnostics when other SMs are used?

I think there's a problem here in a trusted environments given the
approach taken as I've stated in the past but seems to have been
forgotten. The more trust the less the current diag strategy fits.

Are you also going to be proposing exposing MKeys too once MKey
management is supported by OpenSM/other SMs ?

-- Hal

> Sasha