Created attachment 684652 [details] A demonstration of a trivial denial of service attack. Description of problem: Fedora 18 allows any logged in user to perform a denial of service attack against any other user. Version-Release number of selected component (if applicable): Fedora 18. How reproducible: Just put a file in the /run/users/<uid>/ directory with a file that fills the /run filesystem. This is the same problem as bug #830433 with Fedora 16, 17. Though it was supposedly fixed in F18 (though it is still possible to carry out the DOS there too, but at least /var/run is not /run.) Attached is a script log of an attack. Steps to Reproduce: 1.User logs in 2.cd /var/run/user/<users uid> 3.cp /dev/zero ./test Actual results: The /run filesystem is filled with zeros, causing other users to be unable to log in, get credentials, and could also prevent system services from being restarted. Expected results: This is the expected result as long as /run is writable by user processes. Additional info:
It also prevents yum from updating (can't create lock file).
Need quotas on tmpfs.
Need to know how much the system requires so that admins can subtract that from the total size, then divide by the number of concurrent users. Reasonable for small systems, and servers with a limited user base. Doesn't work very well for clusters where users may have multiple logins with different credentials. Think multiple batch jobs where two or three might run simultaneously, and need a different set of credentials. But I need to think more on that. The way things are set now, it looks like they all share the same credentials. On the nice side, at least it all gets deleted when the user logs out. But there may be an issue until the last job of the user finishes. Is there a way to reserve a specified amount for the system to use? That way a user (or a group for that matter) would be unable to DOS the system.
*** This bug has been marked as a duplicate of bug 693253 ***
should also be the same as bug 830433.
I just realized the tmpfs quotas referenced (I believe this http://lwn.net/Articles/466127/ for RLIMIT_TMPFSQUOTA) do not/can not specify WHICH tmpfs limit for which mount. That appears to mean that if /run tmpfs is limited to say 10K, then /tmp (also a tmpfs) is also limited to 10k-what is used for /run. And if /tmp is too limited, then user applications that use /tmp will be just as constrained as their use of /run/user. And if the RLIMIT_TMPFSQUOTA is large enough for /tmp, then the denial of service attack still exists. This would make the RLIMIT_TMPFSQUOTA useless on any system with more than one tmpfs mount that users can access such as the situation with /tmp and /run.