interfaces: recover panics when sanitizing plugs and slots

[zyga]

This branch makes snapd more robust against denial of service attacks in case the interface code that is responsible for sanitization of user-controlled plug/slot definition itself panics.

Signed-off-by: Zygmunt Krynicki zygmunt.krynicki@canonical.com

[stolowski]

I think this is a good idea, it saves us in cases where a bug in sanitize could paralyze snapd. However I think that it will delay a problem to a later stage (when we do connect), and we will inevitably panic anyway, becacuse addConnectedPlug/Slot method will most likely have similar issue to that of Sanitize (or it will panic explicitely because of missing sanitization).
The code in this PR looks fine, but with the above in mind I think we should in addition either: mark the interface as "broken" and do not attempt to connect it later, or handle panics on connect too. What do you think?

[zyga]

@stolowski but if this code fails it will return an error so sanitize won't work so we won't even add the corresponding plug/slot. No way to connect to something that doesn't exist.

[stolowski]

Ah, of course you are right! +1

[niemeyer]

This needs a more detailed conversation, as it's turning the system into an exception mechanism, which panics are not meant to be. Why this and not every single function we call?

Closing for the time being. Let's discuss elsewhere.