Here are the security issues we need to worry about, sorting by resource categories of varying abstraction levels. What we mostly deal with here is avoiding negative consequences of actions by members with legitimate access to our servers.
1. CPU time
We haven't really encountered any trouble with this literal resource yet. However, potential problems come in when we're talking about user dynamic web site programs called by a shared Apache daemon. Apache allocates a fixed set of child processes, and each pending dynamic web site program takes up one child process for the duration of its life. Enough infinite-looping or slow CGI scripts can bring Apache down for everyone.
1.1. Current remedies
As per ResourceLimits, we use patched suexec programs to limit dynamic page generation programs to 10 seconds of running time. We also have a time-out for mod_proxy accesses, which we provide to allow members to implement dynamic web sites through their own daemons that the main Apache proxies.
2. Disk usage
We can't let one person use up all of the disk space, now can we?
2.1. Current remedies
We use group quotas so that members can be charged for files that they don't own. This is still hackish and allows some unintended behaviors. DaemonFileSecurity has more detail.
3. Network bandwidth
We don't do a thing to limit this now, since our current host provides significantly more bandwidth than we need.
3.1. Questions to be resolved
- Should we start doing anything beyond monitoring?
4. Network connection privileges
It's good to follow least privilege in who is allowed to connect to/listen on which ports.
4.1. Current remedies
We have a firewall system in place now. It uses a custom tool documented partially on FirewallRules.
5. Number of processes
Fork bombs are no fun, and many resource limiting schemes are per-process and so require a limit on process creation to be effective.
5.1. Current remedies
As per ResourceLimits, we use the nproc ulimit.
6. RAM
This is probably the most surprising thing for novices to the hosting co-op planning biz. If you would classify yourself as such, then I bet you would leave RAM off your list of resources that need to be protected with explicit security measures!
Nonetheless, it may just be the most critical resource to control. In our experiences back when everything ran on Abulafia, the most common cause of system outage was some user running an out-of-control process that allocated all available memory, causing other processes to drop dead left and right as memory allocation calls failed. We're letting people run their own daemons 24/7, so this just can't be ignored.
6.1. Current remedies
As per ResourceLimits, we use the as ulimit to put a cap on how much virtual memory a process can allocate.