@lemmy04 opened this Issue on October 17th 2019

your suggestion of running a chown -R wwwrun:www on the matomo folder poses a security issue, it can be used to get access to system files:

POC:
sh-5.0$ id
uid=30(wwwrun) gid=8(www) groups=8(www)
sh-5.0$ pwd
/srv/www/matomo
sh-5.0$ ln /etc/shadow shadow

as root:
zypper in -f matomo
ls -lah /etc/shadow
-rw-r----- 3 wwwrun www 1.6K Oct 17 12:07 /etc/shadow

(the matomo rpm for opensuse does that chown -R in %post)

@Findus23 commented on October 17th 2019 Member

Hi,

The matomo opensuse package is not maintained by the matomo team so any issue that's in it should be reported to the maintainers.

I also am not sure I understand your point correctly:
If I create a symlink from testfile -> /etc/shadow and tell root to run sudo chown someuser:someuser testfile that doesn't mean that I make /etc/shadow readable to someuser.

Can you please expand on what exactly is the issue and on how to repoduce it in a normal Matomo installation.

@lemmy04 commented on October 17th 2019

If I create a symlink from testfile -> /etc/shadow and tell root to run sudo chown someuser:someuser testfile that doesn't mean that I make /etc/shadow readable to someuser.

actually you do, if you first set the sysctl fs.protected_hardlinks to 0...

also: the suggestion to run a chown -R does come from matomo. just run a chown -R root:root on the matomo install folder and you'll see it for yourself next time you tr to use matomo.

@toredash commented on October 17th 2019 Contributor

actually you do, if you first set the sysctl fs.protected_hardlinks to 0...

I fail to see why this is an Matomo issue. If the system you install Matomo on is using kernel settings which lowers security outside of "best practice", thats not an issue for Matomo to handle. This would be an issue for any web app then, but it is not.

@lemmy04 commented on October 17th 2019

that still does not change the fact that you (as in, the people working on matomo) are suggesting file system permissions that are way too open. only tmp inside the matomo installation folder needs to be owned by the apache user, not the whole install.

@Findus23 commented on October 18th 2019 Member

only tmp inside the matomo installation folder needs to be owned by the apache user, not the whole install.

If you want to use the GeoIP2-Updater or upload a custom logo /misc also needs to be writable, if you want to use the plugin marketplace plugins needs to be writable and if you want to use the updater everything needs to be writable.

@lemmy04 commented on October 18th 2019

I'm installing matomo through a RPM package, so I definitely am not going to use the updater... the other two folders I can understand and put in the spec file for the RPM package.

@fdellwing commented on October 20th 2019 Contributor

Most webapps need full access to their installation path. I do not see a higher than usual risk in the case of Matomo.

If this is a specific problem with the RPM-package, as you mentioned, this is the wrong issuetracker for this.

@lemmy04 commented on October 30th 2019

guys, I am one of the guys who is working on the RPM package, and what I'm doing here is reporting a problem upstream.

@lemmy04 commented on October 30th 2019

Most webapps need full access to their installation path. I do not see a higher than usual risk in the case of Matomo.

Most webapps that i know only need write access to very specific folders that should at best be kept outside the installation path but I understand how that can't be done for at least the plugin path.

@fdellwing commented on October 30th 2019 Contributor

As @Findus23 already mentioned:

If you want to use a autoupdater, everything needs to be writable by the webserver. I understand that that is not the case with the RPM package. But it needs to be changed in the RPM package than and not in upstream.

@lemmy04 commented on October 30th 2019

I am changing it in the RPM package. I thought you people might be interested in the fact that there's a local prvivilege execution issue with that approach. But from this it looks as if you don't care.

@lemmy04 commented on October 30th 2019

thinking about it some more, how about the RPM package includes a patch that disables the auto updater, and gives the user an appropriate text instead... something like this:

"Matomo version x.y.z has been released, but this installation has been installed through your system's package management, Please inform your system administrator about the update."

Could you guys point me at the right php file to do that?

@lemmy04 commented on October 30th 2019

ok I found enable_auto_update in global.ini.php, that should do it.

Powered by GitHub Issue Mirror