Thanks. I suppose my remaining concern is more of a theoretical one in that case... dnsmasq does not expect untrusted users to supply configuration, and therefore is not overly concerned with risks related to that workflow. As a result, any bugs in dnsmasq's configuration handling become Neutron security risks and therefore OpenStack's responsibility to deal with. In the long term, this does not seem like a sustainable model under which to operate.
In the near term, I agree the proposed solution should suffice, and since it seems to be backportable to all supported stable branches I'll get started on the impact description and coordinated disclosure timeline for an embargoed security advisory.
Thanks. I suppose my remaining concern is more of a theoretical one in that case... dnsmasq does not expect untrusted users to supply configuration, and therefore is not overly concerned with risks related to that workflow. As a result, any bugs in dnsmasq's configuration handling become Neutron security risks and therefore OpenStack's responsibility to deal with. In the long term, this does not seem like a sustainable model under which to operate.
In the near term, I agree the proposed solution should suffice, and since it seems to be backportable to all supported stable branches I'll get started on the impact description and coordinated disclosure timeline for an embargoed security advisory.