FS#25690 - Protect Arch against forkbomb

Attached to Project: Arch Linux
Opened by Mamy Ratsimbazafy (ChoK) - Saturday, 20 August 2011, 15:39 GMT
Last edited by Gaetan Bisson (vesath) - Sunday, 21 August 2011, 20:00 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:
Following the newly implemented security flags in makepkg.conf. I would like to re-raise the issue of forkbombs.

Arch is currently not protected against forkbombs. This means a user can crash his system with no privilege and only a bash shell.

A common solution is to implement user quotas through /etc/security/limits.conf

A discussion was started in 2005 in arch forums https://bbs.archlinux.org/viewtopic.php?id=10884 , I couldn't find a related bug report though.

Steps to reproduce:
Save your work, do not do it on a machine you don't own
Open a bash shell and type one of the following lines :
:(){ :|:& };:
perl -e "fork while fork"&
more(){tail $1 |more}; more /etc/security/limits.conf
This task depends upon

Closed by  Gaetan Bisson (vesath)
Sunday, 21 August 2011, 20:00 GMT
Reason for closing:  Won't implement
Comment by Rémy Oudompheng (remyoudompheng) - Saturday, 20 August 2011, 16:31 GMT
Could you explain what you would like to see implemented ?
Comment by Gaetan Bisson (vesath) - Sunday, 21 August 2011, 09:06 GMT
I believe he suggests bounding the number of processes per user. That sounds to me like a pretty bad idea. If you really need it, feel free to customize your limits.conf, but we shouldn't enforce that as a default for everyone.
Comment by Michael Kühn (breiti) - Sunday, 21 August 2011, 09:19 GMT
I would agree with vesath. Guessing/Enforcing a default value is in my opinion not the preferred way, also because the number of max. processes would differ from system to system (hardware, ram, configuration, users, environment, ...)
Comment by Mamy Ratsimbazafy (ChoK) - Sunday, 21 August 2011, 09:29 GMT
I would like arch to be by default resilient against forkbombs from non-privileged users.
Many solutions exist (grsecurity, bastille, fork bomb defuser module) but except from a default preconfigured /etc/security/limits.conf they all involve installing additional packages.

For your information :
bastille recommends a maxprocess limit of 150 for the group "users", Debian uses a fixed 256, freebsd dynamically determine it according to the RAM (common values seem to be 1789 and 5547).

Those limits don't affect root, boot process will not be impacted.

I would like to see a sane default and also a comment about that in the Install guide, especially for multi seat users and server users). Of course if there are any other solution which does not set a fixed value but a value derived from the system capability, I'd be happy to discuss it.
Comment by Robert Petranovic (jazzfan) - Sunday, 21 August 2011, 12:22 GMT
I believe something like:

* - nproc 500

in /etc/security/limits.conf would be sufficient. I use it without problems for years.

150 seems a like it could cause troubles, while 500 won't. Thus it efficiently denies fork bombs.

Also, may I suggest adding:
session required pam_limits.so

in /etc/pam.d/{su,sudo}, so that limits apply even to users not using login at all.
Comment by Sverd Johnsen (sjohnsen) - Sunday, 21 August 2011, 17:23 GMT
Breaking user space by overriding kernel defaults sounds like a shitty idea. imho: If you want this feature, do it yourself like everyone else.
Comment by Gaetan Bisson (vesath) - Sunday, 21 August 2011, 19:10 GMT
Mamy, Robert: I understand you use these settings happily; but why force them on everyone?
People use Arch in different ways, which results in different setups: the limit that works for you might not work for others.
Besides, we ship the limits.conf provided by PAM upstream; I would suggest that you take your request there.
Comment by Jelle van der Waa (jelly) - Sunday, 21 August 2011, 19:14 GMT
I would like to see a wiki article rather than forcing users to use these settings. In the end you would learn more from a wiki article, plus most people dont need these settings.
Comment by Robert Petranovic (jazzfan) - Sunday, 21 August 2011, 19:19 GMT
Gaetan:
simply because a user who knows will easily change the settings (that user must change it *anyway*).
user who doesn't know won't change that setting. If default is unrestricted, he will be victim of DOS attacks, while if default is restricted, he wont.

We don't do any harm with this, IMO.
Comment by Gaetan Bisson (vesath) - Sunday, 21 August 2011, 19:29 GMT
Robert: Users who don't know about this setting should really not be administrating systems with untrusted users.
Comment by Robert Petranovic (jazzfan) - Sunday, 21 August 2011, 20:00 GMT
  • Field changed: Percent Complete (0% → 100%)
Gaetan: Sure they shouldn't but they can, and they probably will. It still doesn't harm anyone.

Loading...