ip_allow vs. Intercept

[Alan Carroll]

This came up on a production system this week, and although I understand
what was going on, it's not so clear to me if this is a bug or a feature.

If you set up ip_allow.config to block some specific methods, this access
check is done at the end of remapping. However, if a plugin calls
TSSkipRemappingSet(txn, 1), then remap is skipped, which skips end of
remap, which skips the access check. This is commonly done with intercept
plugins. In that case if the method in question is CONNECT, it looks like
the CONNECT went through, bypassing ip_allow, but it has actually been
intercepted and the CONNECT has connected to the intercept plugin, not the
destination in the CONNECT request. That can be nice - if I'm intercepting
transactions, I want to handle that kind of thing. It also seems reasonable
to take the view point that if ip_allow doesn't permit the request, it
shouldn't be permitted even for internal transactions.

Overall, I think I favor enforcing ip_allow even on intercept plugins. Any
other thoughts?

[Derek Dagit]

I also favor enforcement even on intercept plugins.

ip_allow is a white-listing function that is often configured to implement
a security policy.

If one wishes to bypass it, then we could make such a thing explicit via
the plugin API.

On the other hand it would be nice of there were big, red, ugly warnings
around any plugin API that could cause it to unexpectedly fail open.

On Thu, Dec 6, 2018 at 4:43 PM Alan Carroll

Post by Alan Carroll
This came up on a production system this week, and although I understand
what was going on, it's not so clear to me if this is a bug or a feature.
If you set up ip_allow.config to block some specific methods, this access
check is done at the end of remapping. However, if a plugin calls
TSSkipRemappingSet(txn, 1), then remap is skipped, which skips end of
remap, which skips the access check. This is commonly done with intercept
plugins. In that case if the method in question is CONNECT, it looks like
the CONNECT went through, bypassing ip_allow, but it has actually been
intercepted and the CONNECT has connected to the intercept plugin, not the
destination in the CONNECT request. That can be nice - if I'm intercepting
transactions, I want to handle that kind of thing. It also seems reasonable
to take the view point that if ip_allow doesn't permit the request, it
shouldn't be permitted even for internal transactions.
Overall, I think I favor enforcing ip_allow even on intercept plugins. Any
other thoughts?
--
*Beware the fisherman who's casting out his line in to a dried up riverbed.*
*Oh don't try to tell him 'cause he won't believe. Throw some bread to the
ducks instead.*
*It's easier that way. *- Genesis : Duke : VI 25-28