[api-sig][neutron] Question on oslo policy assertion when supplied attribute equals the default

Nate Johnston nate.johnston at redhat.com
Tue Apr 23 15:47:59 UTC 2019


On Tue, Apr 23, 2019 at 11:01:36AM -0400, Brian Haley wrote:
> On 4/23/19 9:57 AM, Ben Nemec wrote:
> > 
> > 
> > On 4/23/19 8:33 AM, Michael McCune wrote:
> > > On Tue, Apr 23, 2019 at 3:19 AM Slawek Kaplonski
> > > <skaplons at redhat.com> wrote:
> > > > But in some corner case it might be even patched and defaults
> > > > can be different
> > > > in some specific cloud.
> > > 
> > > after replying to Nate last night, this was the only corner case i
> > > could think of as well. there /could/ exist a situationĀ  where an
> > > operator has modified the defaults such that they are not in the
> > > upstream source, in this case the "default hunting" could be seen as
> > > an exposure of information. whether that information is useful or not,
> > > i am still not sure about but it's worth noting. good observation =)

Chatting with amotoki on IRC I realized that "defaults" is a somewhat
ambiguous term - there are the defaults set in code when we release
OpenStack, and then there are the values that an operation defaults to
while running, which can be influenced by the configuration of the
running cloud.  Just to be clear, I meant the latter when I referred to
"defaults".

In other words, if the sent value had not been sent, what would have
been applied for that action?  I.e. if I sent a create route request
without "ha" specified, then is the resulting router created with
ha=false?  Then the value to pass through is ha=false.

For example, anyone can create a port but only an admin or network owner
can create a port with port security specified.  Here is the result
matrix for a create port request by a non-admin user that does not own
the network in an environment where ports are created with port security
enabled by default.

                  |   without proposal    |  with proposal       |
port_security     |                       |                      |
requested         |                       |                      |
------------------|-----------------------|----------------------|
enabled           |  Denied by policy     | OK (same as default) | 
------------------|-----------------------|----------------------|
disabled          |  Denied by policy     | Denied by policy     |
------------------|-----------------------|----------------------|

> > Assuming you have permission to make the API call in the first place,
> > wouldn't you be able to determine the defaults based on the results of
> > the API call anyway? As in, I create a network and don't pass any value
> > for the shared attribute, then I look at the created network and see
> > that shared is False by default.
> 
> Maybe an example would make it clearer.  If as an admin I want to enable DVR
> and L3-HA, I make some changes in neutron.conf to set that as the default.
> When a user creates a router there will be many objects created and extra
> daemons spawned, as opposed to the case when there is just centralized
> routing.  An 'openstack router show routerX' won't return the distributed or
> ha values in the API response unless you are the admin user, so there isn't
> a way to determine the defaults.
>
> > Maybe there are defaults that aren't so easily observable, but in
> > general I wouldn't consider them sensitive data. However, I am not a
> > security guru so take my opinion for what it's worth.
> 
> In the above case, is knowledge of the router type sensitive data? Probably
> not, if I'm remembering correctly I think we kept them hidden since it's the
> admin that made the decision on the deployment, and users might get
> confused.  But if you knew your router was distributed then you'd know there
> was something local to your hypervisor (router namespace), instead of only
> on a remote controller node.  Again, probably not an issue, but it does let
> you know what additional agents might be running where your instance is.

I'm not sure how such knowledge would be usable without breaking the
containment of the instance; if such knowledge is exploitable I think it
would warrant a CVE.  

> Nate - I'm assuming your changes wouldn't allow users to figure something
> like this out based on making a series of API calls?

Yes, it would allow a user to determine the defaults.  Since I scoped my
proposal to boolean fields, in fact it would take at most two to check.
As you mentioned before, my understanding is that we did not share some
of the back-end implementation details for usability concerns - not
confusing users - as opposed to a security/separation of concerns
approach.  If there are fields where the defaults should not be
detectable by this kind of inspection then I definitely want to know,
but I cannot think of any at this time.

What does it benefit an attacker to know that ports are created with
port security on by default, or that networks are created as not shared
by default, or routers are or are not HA by default?  I am hoping that
by airing this in the community, perhaps others will see angles I
cannot.

Thanks,

Nate



More information about the openstack-discuss mailing list