Open Stack

On Nov 13, 2014, at 8:47 PM, Jamie Lennox <jamielennox at redhat.com> wrote:

> Hi all,
> 
> To implement kite we need the ability to sign and encrypt the message and the
> message data. This needs to happen at a very low level in the oslo.messaging
> stack. The existing message security review
> (https://review.openstack.org/#/c/109806/) isn't going to be sufficient. It
> allows us to sign/encrypt only the message data ignoring the information in the
> context and not allowing us to sign the message as a whole. It would also
> intercept and sign notifications which is not something that kite can do.
> 
> Mostly this is an issue of how the oslo.messaging library is constructed. The
> choice of how data is serialized for transmission (including things like how
> you arrange context and message data in the payload) is handled individually by
> the driver layer rather than in a common higher location. All the drivers use
> the same helper functions for this and so it isn't a problem in practice.
> 
> Essentially I need a stateful serializing/deserializing object (I need to store
> keys and hold things like a connection to the kite server) that either extends
> or replaces oslo.messaging._drivers.common.serialize_msg and deserialize_msg
> and their exception counterparts.
> 
> There are a couple of ways I can see to do what I need:
> 
> 1. Kite becomes a more integral part of oslo.messaging and the marshalling and
> verification code becomes part of the existing RPC path. This is how it was
> initially proposed, it does not provide a good story for future or alternative
> implementations. Oslo.messaging would either have a dependency on kiteclient,
> implement its own ways of talking to the server, or have some hack that imports
> kiteclient if available.
> 
> 2. Essentially I add a global object loaded from conf to the existing common
> RPC file. Pro: The existing drivers continue to work as today, Con: global
> state held by a library. However given the way oslo messaging works i'm not
> really sure how much of a problem this is. We typically load transport from a
> predefined location in the conf file and we're not really in a situation where
> you might want to construct different transports with different parameters in
> the same project.
> 
> 3. I create a protocol object out of the RPC code that kite can subclass and
> the protocol can be chosen by CONF when the transport/driver is created. This
> still touches a lot of places as the protocol object would need to be passed to
> all messages, consumers etc. It involves changing the interface of the drivers
> to accept this new object and changes in each of the drivers to work with the
> new protocol object rather than the existing helpers.
> 
> 4. As the last option requires changing the driver interface anyway we try and
> correct the driver interfaces completely. The driver send and receive functions
> that currently accept a context and args parameters should only accept a
> generic object/string consisting of already marshalled data. The code that
> handles serializing and deserializing gets moved to a higher level and kite
> would be pluggable there with the current RPC being default.
> 
> None of these options involve changing the public facing interfaces nor the
> messages emitted on the wire (when kite is not used).
> 
> I've been playing a little with option 3 and I don't think it's worth it. There
> is a lot of code change and additional object passing that I don't think
> improves the library in general.
> 
> Before I go too far down the path with option 4 I'd like to hear the thoughts
> of people more familiar with the library.
> 
> Is there a reason that the drivers currently handle marshalling rather than the
> RPC layer?

It may have been an artifact of the evolution of that code, but I seem to remember at some point that one of the drivers had a limitation either in the byte-values allowed or the number of bytes allowed in a message. They all seem to be doing roughly the same thing to construct the messages now, though, so I’m not sure if that’s really true.

> 
> I know there is ongoing talk about evolving the oslo.messaging library, I
> unfortunately didn't make it to the sessions at summit. Has this problem been
> raised? How would it affect those talks?

Security did come up, but I don’t see where we recorded any decisions in the etherpad: https://etherpad.openstack.org/p/kilo-oslo-oslo.messaging

Our bigger concern was lack of reviewers for the library, which will make any large-scale refactoring problematic.

> 
> Is there explicit/implicit support for out of tree drivers that would disallow
> changing these interfaces?

There’s implicit support, but we haven’t formally called those APIs stable.

> 
> Does anyone have alternative ideas on how to organize the library for message
> security?
> 
> Thanks for the help.
> 
> 
> Jamie
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev