On a webserver with a bunch of Wordpress sites, I was noticing that something
was invoking /usr/local/bin/curl to make some request. It was happening very
frequently, and each request was failing because, well, Wordpress and PHP.
I finally tracked it down to an awesomely horrific file called
class-snoopy.php. It’s not realistic nor practical for me to patch each
matching file on the system (nor would I want to), and so I looked at
restricting access to /usr/local/bin/curl instead.
The obvious thing to do would be to run:
chmod o-x /usr/local/bin/curlThis certainly accomplishes the goal of preventing class-snoopy.php from
invoking a new process, but has a side effect of also preventing all regular
shell users from running curl.
Enter FreeBSD ACLs.
First, one must mount the filesystem to support this feature:
# /mountpoint would be replaced with whatever mountpoint you're working with
sudo mount -u -o acls /mountpointYou’ll also want to update /etc/fstab to include the acls option for your
relevant mountpoint(s) so that after rebooting, it’s still enabled.
Update: The preferred method for activating ACLs is to actually use
tunefs(8):
tunefs -a enable /mountpointBut you’ll have to unmount the filesystem first—either by dropping down to
single user mode (shutdown now) or simply umount /mountpoint if it’s not
a crucial filesystem.
Next, let’s prevent the www user from accessing curl:
setfacl -m u:www: /usr/local/bin/curlWe can take a peek at our new ACL with the getfacl command:
# file: /usr/local/bin/curl
# owner: root
# group: wheel
user::r-x
user:www:---
group::r-x
mask::r-x
other::r-xYou’ll notice the user:www:--- line which shows us that the www user now has
no permissions to this file.
Of course, the better solution would be to just forbid any Wordpress sites and instead force everyone to use Jekyll, but that’s another post…