the status page is not needed for dolibarr, AND it might be revealed if you have a proxy in front of dolibarr

[JonBendtsen]

the status page is not needed for dolibarr, AND it might be revealed if you have a proxy in front of dolibarr because traffic will seem to be local because it comes from the proxy :-(

[creekorful]

Hello @JonBendtsen,

I don't think we need this PR if we add a way to disable the modules here in this PR #47. That would be much more convenient.

[JonBendtsen]

Hello @JonBendtsen,

I don't think we need this PR if we add a way to disable the modules here in this PR #47. That would be much more convenient.

I totally disagree, this is actually even more needed than PR#47 because this is a potential leak of information about the Dolibarr server setup.

• It makes no diffference for Dolibarr if apache has this status page or not

• the status page will reveal information about the setup, information that people don't need. Yes this status page by default is for local connections only - but more and more people run containers in Kubernetes or some other container behind a proxy, and unless the setup is done correctly, to apache inside the dolibarr container the proxy will seem to be a local connection and then it will respond with the status page - something we don't want. So let's close this information leak.

Those that need the status page can enable it.

[cibero42]

Hey @creekorful ,

I need to agree with @JonBendtsen on disabling this module, since it may provide an adversary with information that can be used to refine exploits that depend on measuring server load, as per CIS Benchmark recomendations.

I'm a defensor of the "Secure by design" philosophy, and I think that we shouldn't expect a regular user to think about disabling this by themselves.

I disagree with PR #47 though - as @tuxgasy mentioned, we already have a feature that allow advanced users to enable modules and do their modifications.

[JonBendtsen]

I disagree with PR #47 though - as @tuxgasy mentioned, we already have a feature that allow advanced users to enable modules and do their modifications.

Then why not do the same with the PHP settings?

[tuxgasy]

I disagree with PR #47 though - as @tuxgasy mentioned, we already have a feature that allow advanced users to enable modules and do their modifications.

Then why not do the same with the PHP settings?

I agree to apply the same rule for PHP. PHP settings was integrated before the init script.

[JonBendtsen]

@tuxgasy I dont think that PHP settings should be removed

[creekorful]

(Copy paste of my answer from this other PR)

Since there is a consensus for the base image to provide sane (and safe) defaults, let's move on with this PR.

On a side note I would be great to check the list of enabled apache modules and use this PR to disable all modules who does not need to be enabled.

If the user is willing to enable a module this could be done using the custom init scripts like @tuxgasy explained in another PR.

Cheers,

[creekorful]

Can we move this to another RUN instruction just after this one and before the "Get Dolibarr" one?

Something like this:

# Disable useless Apache modules to provide safe defaults
RUN a2disconf status

[cibero42]

@tuxgasy I think that removing current PHP envs will lead to the creation of issues and confusion, from users unaware of these changes.

Sadly envs is one of the things that it is hard to remove without creating a little "chaos".

We can assume that those who use this envs are advanced users, and we can create a big text on the beginning of the README regarding these changes, but we will for sure disrupt some production environments by doing so.

[cibero42]

On a side note I would be great to check the list of enabled apache modules and use this PR to disable all modules who does not need to be enabled.

Perhaps we can have a look on CIS Benchmark recomendations - it should be a good start.

[JonBendtsen]

replaced by #54

[creekorful]

Closing as superseded by #54.