Bug 1778052

Hello there,

All is managed in puppet-openstacklib, so hopefully one patch only is needed.

This is probably affecting all of OSP versions though, so it will take some time to do the appropriate backports. In fact, I think we might be able to deactivate the Index option for *all* locations, since we probably want to disallow Directory Listing. Right?

Putting DFG:Security and needinfo() on Nathan to raise their awareness and get some feedback.

Cheers,

C.

Hi Cédric,


Thank you for working about this issue.

I tried the change you proposed in my local, by restarting nova_api after removing Index in /var/lib/config-data/puppet-generated/nova/etc/httpd/conf.d/10-nova_api_wsgi.conf,
but I'm afraid that we still can see the Index page.
After some more investigation about the reson, I found that the index is enabled by /etc/httpd/conf.d/autoindex.conf, which should be also fixed.
You can find a bug about that file filed on bugzilla[1] .
It seems that current puppet-apache expects these configuration files located under /etc/httpd/conf.modules.d,
and we don't have any mechanism to delete these files under /etc/http/conf.d  .

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1729423


In addition, while we don't see index page after removing Index also in autoindex.conf, we still see that we can access to files under icons.

~~~
[heat-admin@controller-0 ~]$ sudo docker restart nova_api
nova_api
[heat-admin@controller-0 ~]$ sudo docker exec -it nova_api cat /etc/httpd/conf.d/autoindex.conf
...
IndexOptions FancyIndexing HTMLTable VersionSort

# We include the /icons/ alias for FancyIndexed directory listings.  If
# you do not use FancyIndexing, you may comment this out.
#
Alias /icons/ "/usr/share/httpd/icons/"

<Directory "/usr/share/httpd/icons">
    Options MultiViews FollowSymlinks
    AllowOverride None
    Require all granted
</Directory>

...
[heat-admin@controller-0 ~]$ sudo docker exec -it nova_api cat /etc/httpd/conf.modules.d/alias.conf
<IfModule alias_module>
Alias /icons/ "/usr/share/httpd/icons/"
<Directory "/usr/share/httpd/icons">
    Options None
    AllowOverride None
    Require all granted
</Directory>
</IfModule>
[heat-admin@controller-0 ~]$ curl -I -v http://172.17.1.10:8774/icons/unknown.gif
* About to connect() to 172.17.1.10 port 8774 (#0)
*   Trying 172.17.1.10...
* Connected to 172.17.1.10 (172.17.1.10) port 8774 (#0)
> HEAD /icons/unknown.gif HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 172.17.1.10:8774
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
< Content-Length: 245
Content-Length: 245
< Content-Type: image/gif
Content-Type: image/gif

...
~~~

I think this is because we have alias configuration in /var/lib/config-data/puppet-generated/nova/etc/httpd/conf.modules.d/alias.conf (which I tried to fix in my patch),
and that autoindex.conf inside docker container.
I believe that we also should fix them because we don't need them exposed.

Please let me know if you find anything wrong with my above findings.

Thank you,
Takashi

Hello Takashi,

Ah, good finding for the other autoindex.conf thing, I'll investigate that one once my current deploy is over.

Regarding the fact that icons are still available - it's not a real issue imho:
- not really resource-hungry
- if no auto-index, no real way to discover them (nor do some directory structure discovery)
- API are supposed to be consumed by automated tools, not human
- I don't see why having the ability to point to an exact, known name is an issue

On the other hand, if we're wanting to not expose that anymore, it will probably make things more complicated within the whole tripleo templates - not sure of the benefits... ?

I propose we first solve the auto-index issue, since this one is really causing some problems (tree discovery and so on), and if there is a real concern about icon availability, we can try to find an elegant solution. Fact is, static content is supposed to be served by httpd directly - so it shouldn't impact wsgi itself.

Does it sounds like a plan?

Thank you for your feedback!

C.

Hi Cédric,


Sorry for my late reply.

I'm agree with you about the less benefits about disabling the direct access to files under icons
and the plan sounds good to me.
Maybe we can create another independent bug with low priority about direct access.

Thank you,
Takashi

Update: started upstream backports in // down to Queens. Related links are added here.

Hello,

OSP-13 backport in the pipes - OSP-15 and OSP-16 should already have the patch available (at least it's listed in their respective downstream branch), no need to create BZ for those two.

If everything goes well, it should be available in the next z-stream for OSP-13.

Cheers,

C.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0760