1

Are there any special steps that should be taken to secure Gallery? Specifically, I currently have the Fedora RPM gallery2-2.3-1.fc8 installed. I do have selinux enabled in targeted mode, which is a good layer of protection. I found the Gallery security documentation. I was just wondering if there was anything else I should look at to ensure that this is secure against external attack.

I am far less worred about local attack. I just want to ensure that exposing this to the public internet won't get my server hacked.

5 Answers 5

3

Gallery has raised money for security audits of the core packages. They do a pretty good job. I'd trust them more then wordpress for example. Both products do suffer from the same problem, none of the plugins are sandboxed and often do stupid things. Keep light on the plugins (the core or most popular ones) and you'll be alright.

Also of course, try to run each application as a different user, to contain security breaches. And keep the gallery data folder out of the document root. Gallery also likes memory so if you can turn your php memory limit up a bit it always improves performance.

1

The Gallery security docs are pretty thorough; if you secure Gallery that much, your main concern should be other avenues of attack like bugs in php itself or in ssh or whatever other services you're running.

1

Gallery itself seems fairly secure, just ensure you run the latest stable versions and keep on top of updates.

1

Agreed; the Gallery team is pretty good about keeping their code well maintained.

That said, the best security for any PHP app is the server itself. Make sure you're not running Apache as root, don't waste time with so-called safe_mode, disable directory indexes, don't leave backup files (such as vi's foo.bar~ files around where a config file containing your mysql password may be stored) around.

1

With SELinux targeted policy enabled you should really check what SELinux context/domain your network facing (or localuser facing) services are running as. Try the -Z option for ps. if it is unconfined_u:unconfined_r:unconfined_t it isn't doing much for you. You can change this of course by installing the right policy module is installed (see tools such as seinfo, semanage, semodule). If you don't have a defined policy for the service/app then you need to create your own. Tools exist now that help this, such as SLIDE (eclipse plugin) and seedit. You will need to look at your audit logs (typically /var/log/audit/audit.log)

2
  • +1. I didn't know about the -Z option to ps. Looking, there is very very little running as not-me that is unconfined. It's mostly bash (from a single su session) and a few custom scripts that are not internet-facing. Everything else running that is not from my non-root GNOME session is confined.
    – Eddie
    Jun 20, 2009 at 18:42
  • very very quick and dirty one liner to get current state of ip4 sockets. This is just for the idea, customize to get the information you want. for pid in lsof -i 4 | awk '{print $2}' | sort -u | head -n -1 ; do ps --pid $pid -Z ; done
    – rev
    Jun 23, 2009 at 16:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .