Bug 609856 - cacti: no httpd restrictions for log and rra directories
Summary: cacti: no httpd restrictions for log and rra directories
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: cacti
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-01 10:39 UTC by Tomas Hoger
Modified: 2011-12-29 22:02 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-11 21:20:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tomas Hoger 2010-07-01 10:39:32 UTC
Description of problem:
Upstream cacti tarballs have log and rra as subdirs in main cacti directory.  They both contain .htaccess file that prevents access to files in those directories via httpd.

In Fedora cacti packages, those directories are replaced by symlinks to directories created elsewhere (in /var), but there's no restriction equivalent to .htaccess files provided by upstream.  So it is possible to download log or rra files (if you can guess their names).

Default cacti-httpd.conf only allows localhost to access cacti, but I believe this restriction is more of a safe default before cacti can be configured and expected to be removed.  It may be a good idea to extend default httpd config to clarify purpose of default localhost restriction and add additional restrictions on log and rra (and scripts possibly too) not expected to be removed after initial configuration.

Version-Release number of selected component (if applicable):
cacti-0.8.7f-1

Comment 1 Bug Zapper 2010-07-30 12:21:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 2 Ken Dreyer 2011-04-05 02:52:32 UTC
(This is still present in rawhide, so I'm bumping the version back up.)

When I looked into this problem a while ago, I came up with a "blacklist" of things that should never be loaded. Here's a snippet of my httpd.conf

<Directory /var/www/cacti/>
<FilesMatch (cmd|copy_cacti_user|poller|poller_commands|poller_export|poller_reindex_hosts|rebuild_poller_cache|script_server).php>
        order deny,allow
        Deny from all
</FilesMatch>
</Directory>

<Directory /var/www/cacti/scripts>
    order deny,allow
    Deny from all
</Directory>
<Directory /var/www/cacti/include>
    order deny,allow
    Deny from all
    <FilesMatch (.gif|.css|.js)$>
        order allow,deny
        Allow from all
    </FilesMatch>
</Directory>

Feel free to use this for inspiration. You could certainly add /rra and /log to the blacklist.

Comment 3 Fedora Admin XMLRPC Client 2011-04-05 14:09:54 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Gwyn Ciesla 2011-04-05 15:48:46 UTC
Please test this update.  It's built for F-14, but I'd like it tested before I put it in rawhide or older.

Thanks!

http://zanoni.jcomserv.net/fedora/cacti/cacti-0.8.7g-3.fc14.noarch.rpm

Comment 5 Ken Dreyer 2011-04-06 09:46:36 UTC
Jon,

I took a look at that RPM. Here are my three suggestions:

1. On the original subject of this bug, I don't see the /log or /rra directories denied anywhere. You should probably insert the following additional sections to /etc/httpd/conf.d/cacti.conf:

<Directory /usr/share/cacti/log>
    order deny,allow
    Deny from all
</Directory>
<Directory /usr/share/cacti/rra>
    order deny,allow
    Deny from all
</Directory>

2. To keep with the "localhost only, out of the box" convention, you should probably modify my suggested configuration from "Allow from all" to "allow from 127.0.0.1" in the /include directory. It would look like this:

<Directory /usr/share/cacti/include>
    order deny,allow
    Deny from all
    <FilesMatch (.gif|.css|.js)$>
        order allow,deny
        Allow from 127.0.0.1
    </FilesMatch>
</Directory>

3. To help out the user, it would be useful to add a note in either README.cacti or etc/httpd/conf.d/cacti.conf (my preference). Something like:

# Users: Change "Allow from 127.0.0.1" to open up cacti to other network devices. For example, change "Allow from 127.0.0.1" to "Allow from all".
# The sections marked "deny from all" should not be modified. These are in place in order to harden cacti.

Comment 6 Ken Dreyer 2011-10-27 22:52:04 UTC
Initial fix committed in 236450cab3.

Comment 7 Fedora Update System 2011-11-11 16:16:06 UTC
cacti-0.8.7h-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/cacti-0.8.7h-2.fc16

Comment 8 Fedora Update System 2011-11-25 02:25:38 UTC
cacti-0.8.7h-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Fedora Update System 2011-12-12 15:24:40 UTC
cacti-0.8.7i-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/cacti-0.8.7i-1.el6

Comment 10 Fedora Update System 2011-12-12 15:27:00 UTC
cacti-0.8.7i-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/cacti-0.8.7i-1.el5

Comment 11 Fedora Update System 2011-12-12 15:30:04 UTC
cacti-0.8.7i-1.el4 has been submitted as an update for Fedora EPEL 4.
https://admin.fedoraproject.org/updates/cacti-0.8.7i-1.el4

Comment 12 Fedora Update System 2011-12-29 22:00:20 UTC
cacti-0.8.7i-2.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2011-12-29 22:02:04 UTC
cacti-0.8.7i-2.el4.1 has been pushed to the Fedora EPEL 4 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2011-12-29 22:02:19 UTC
cacti-0.8.7i-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.