Snuffleupagus 0.10.0 when loaded via Apache only applies ruleset when it has no comments

[demonfoo]

I'm experimenting with using Snuffleupagus to further secure our PHP runtime environments. With 0.9.0, the ruleset I'd worked up applies and catches denied function calls, and with 0.10.0, when run via the PHP CLI it does as well.

However, I discovered that with 0.10.0, the same ruleset does... literally nothing with PHP loaded into Apache. I removed everything but a single drop() directive and it worked, then I tried re-adding some other material and it again didn't work.

A bit more experimentation revealed that, when I removed all the inline comments, the ruleset then worked. I'm not sure why it's only when loaded via Apache, but that is definitely the case; after removing comments, the function drop() directives work as expected.

Please let me know what further information I can provide. Thanks.

[jvoisin]

This sounds both equally wrong and horrible.

The configuration parser was a bit simplified in cee5535, so odds are that if something is wrong, it should be in it. However, Snuffleupagus doesn't care whether it's running under Apache or whatever else.

Do you have some funky sandboxing going on with Apache that might prevent the php process from reading the rules? If it's the case, Snuffleupagus should complain about it in its logs and in a phpinfo() call.

You can use the SP_DUMP_CONFIG environment variable to dump the whole thing.

[demonfoo]

We are using chroot() with Apache via the ChrootDir directive, but I hardlinked the config file inside the chroot() environment at the same path. I also did an strace of Apache running, and I only saw the parent process reading the rules file the one time, there were no attempts in the child processes to walk /etc/php.d/ and re-read the config file. Also, the fact that the same config directives are now working so long as the comments are removed would seem to point to something with the parsing, though obviously I can't say what.

[demonfoo]

Also, it did not complain about any parsing issues in either the Apache log file or in phpinfo() output; I'd been loading a bit of PHP calling phpinfo() (as it's one of the functions I meant to block), and it showed the php.ini config directives and no complaints about parsing issues. It just seems that anything past a comment line just got ignored, like it didn't see the newlines or something?

[jvoisin]

Also, the fact that the same config directives are now working so long as the comments are removed would seem to point to something with the parsing, though obviously I can't say what.

Indeed, but you said that it's working in the cli, which is super-duper-confusing :/

Are you sure you're running the same versions in the cli and in apache?

[demonfoo]

Yes, there's only a single snuffleupagus.so on the machines in question. It's installed via the Remi RPMs, though I did notice they don't depend on re2c (I tried rebuilding them via rpmbuild), so it apparently doesn't regenerate the generated .c file? I don't know if that's a problem or not.

[jvoisin]

@remicollet might know :)

Anyway, the plot thickens! I'll try to play with comments in configuration files maybe tomorrow, more likely this weekend.

[demonfoo]

FWIW, I tried to use my rebuilt RPM with a copy of the config with the comments restored, and it did the same thing (I built the package with re2c installed on the host). So that doesn't seem to make a difference.

[jvoisin]

I didn't manage to reproduce the issue on my end :/

[nickchomey]

Can I suggest dumping put the phpinfo()/php -i for cli and for Apache? It's entirely possible they're using different ini files