Bug 902522

Summary: Denial of service attack using /run
Product: [Fedora] Fedora Reporter: Jesse Pollard <pollardwaldorf>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: dennis, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, schaiba
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-22 20:49:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A demonstration of a trivial denial of service attack. none

Description Jesse Pollard 2013-01-21 20:56:21 UTC 
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:
Comment 1 Jesse Pollard 2013-01-21 21:09:34 UTC 
It also prevents yum from updating (can't create lock file).
Comment 2 Bill Nottingham 2013-01-22 19:30:26 UTC 
Need quotas on tmpfs.
Comment 3 Jesse Pollard 2013-01-22 19:57:52 UTC 
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.
Comment 4 Josh Boyer 2013-01-22 20:49:51 UTC 

*** This bug has been marked as a duplicate of bug 693253 ***
Comment 5 Jesse Pollard 2013-01-22 22:43:23 UTC 
should also be the same as bug 830433.
Comment 6 Jesse Pollard 2013-01-22 23:34:41 UTC 
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.