RHEL7 document git and proxy to make update via web interface work

[liedekef]

Work environment

Questions	Answers
Type of issue	Bug
OS version (server)	RedHat, ...
OS version (client)	7
PHP version	scl 7.1...
MISP version / git hash	2.4 latest
Browser	If applicable

Expected behavior

Update starts

Actual behavior

After fixing the git tag to point to 2.4, update from the web interface should work. However, clicking on the button gives me a grayed out screen (like an overlay popup not being shown), but nothing else happens. There's nothing in /var/log/audit/ pointing to selinux issues, and the logs in app/tmp/logs are not showing anything too. It seems something is being blocked, but I can't pinpoint it.

[liedekef]

Ok, follow-up: it seems the popup is not working in google chrome, but it is working in internet explorer.
However, now new permission issues are popping up (fyi: selinux is active, the .git subdir is owned by the http-process user):

git checkout app/composer.json 2>&1

fatal: Unable to create '/var/www/MISP/.git/index.lock': Permission denied

git pull origin 2.4 2>&1

fatal: Unable to create '/var/www/MISP/.git/index.lock': Permission denied
error: cannot open .git/FETCH_HEAD: Permission denied

Edit: when disabling SELinux (just to try), I get this in the logs:

2019-02-12 14:41:40 Error: [BadRequestException] The request has been black-holed
Request URL: /servers/update

[SteveClement]

Hmm, try to reset the permissions as per the Centos guide, it might be more up to date:

https://misp.github.io/MISP/xINSTALL.centos7/#5-set-the-permissions

[liedekef]

Besides the black-holed issue (help on that please), the documentation for both redhat and centos is missing some stuff: one should not use chcon (unless for quick testing), but semanage+restorecon. Reason: when the next selinux relabel happens, all those selinux contexts would be reset otherwise.
But currently the problem with selinux permissions appears to be that the webserver homedir is also being used to write temporary stuff in (subdir .pki/nssdb being created), and selinux is not allowing that.

[SteveClement]

I see, I would need to dig much deeper into CentOS/RHEL to make it cleaner.
Thus I cannot really help you yet.

[iwitz]

Are you using a web proxy ? The function that updates MISP doesn't take the web proxy parameter into account when updating which can cause the update through the web interface to "hang" ( because git is waiting for an HTTP response that it is not getting ). If you run ps -e | grep git after trying to update, do you have git processes ?
I'll submit a PR for this tomorrow.

[liedekef]

While I am using a proxy, I configured git to also use the proxy (using "git config http.proxy" and "git config https.proxy"), I don't see a need for a PR-request for this.
To summarize:

• the popup to confirm the update is not working in chrome, only in IE (this is a shame)
• git works, but I get permission denied because of selinux issues with the webserver home-dir
• the documentation for redhat, centos (in fact, any selinux-enabled distro) is lacking (semanage+restorecon should be used, not just chcon)
• if disabling selinux (to get around things quickly), I get the black-holed message on /servers/update

So any help on the black-holed issue is currently appreciated (and the popup should work in chrome too), otherwise I can't update at all (since it is recommended to use the webinterface for updates ...).

[SteveClement]

@iwitz Thanks for that, yes this typically wants to be in misp-book.

I will bag and tag this one ;)

[liedekef]

I finished my setup in RHEL7, and I'm willing to just take the current doc (the doc for redhat/centos seems to be gone now) and change it so it works :-)

Some things:

• the first part is already wrong: when in "detached head" git mode, the web interface will refuse updates
• you also need to use a newer version of git from scl (so rh-git218 for example)
• php-fpm needs these extra settings in www.conf:

env[PATH] = /opt/rh/rh-git218/root/usr/bin:/opt/rh/rh-redis32/root/usr/bin:/opt/rh/rh-python36/root/usr/bin:/opt/rh/rh-php71/root/usr/bin:/usr/local/bin:/usr/bin:/bin

• if you ever want the update to work via the webinterface, the selinux permissions should be totally different on the whole part. These should be sufficient:

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/MISP(/.*)?"
restorecon -R /var/www/MISP/

• when pip install is finished, you need to set the selinux permissions on those files too:
  restorecon /opt/rh/rh-python36

[chrisinmtown]

I thought the direction from CIRCL is to avoid SE Linux entirely (which is what we do), did I misunderstand?