Open Stack

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 =)
> 
> 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.

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

-Brian