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/curl

This 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 /mountpoint

You’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 /mountpoint

But 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/curl

We can take a peek at our new ACL with the getfacl command:

# file: /usr/local/bin/curl
# owner: root
# group: wheel

You’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…