Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 85656 - Default limits.conf settings allows for non-priviledged users to crash to system
Summary: Default limits.conf settings allows for non-priviledged users to crash to system
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: x86 Linux
: High enhancement (vote)
Assignee: Gentoo's Team for Core System packages
URL: http://forums.gentoo.org/viewtopic-t-...
Whiteboard:
Keywords:
: 85784 86223 176059 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-03-17 08:46 UTC by Mark Lagace
Modified: 2008-07-27 16:20 UTC (History)
19 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
fork_bomb_fix.patch (fork_bomb_fix.patch,397 bytes, patch)
2005-03-21 06:53 UTC, Natanael Copa
Details | Diff
/usr/local/bin/maxproc (test program) (maxproc.c,636 bytes, text/plain)
2005-03-22 01:36 UTC, Natanael Copa
Details
/etc/init.d/testmaxproc (init script for maxproc.c) (testmaxproc,70 bytes, text/plain)
2005-03-22 01:41 UTC, Natanael Copa
Details
maxproc.c (test program) (maxproc.c,648 bytes, text/plain)
2005-03-22 01:44 UTC, Natanael Copa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Lagace 2005-03-17 08:46:45 UTC
A default gentoo install is vulnerable to a 'forkbomb' attack - where a non-priviledged user can create an infinite number of processes and thus overload the system resources.  The default /etc/security/limits.conf file contain NO limits.  There should be some sane default limits.  See the forum topic here:
http://forums.gentoo.org/viewtopic-t-309944.html

Reproducible: Always
Steps to Reproduce:
1.Install Gentoo
2.Log in as a non-priviledged user.
3.Write a small script to infinitely create new processes

Actual Results:  
System crashes.

Expected Results:  
The number of processes I was allowed to create should have been limited.
Comment 1 SpanKY gentoo-dev 2005-03-17 15:34:54 UTC
system crashes only if it sucks

newer kernels can recover from forkbombs
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2005-03-18 08:47:20 UTC
*** Bug 85784 has been marked as a duplicate of this bug. ***
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2005-03-18 08:48:51 UTC
vapier: according to the dupe bug, 2.6.9 does not really recover... maybe a sane default value could be put into limits.conf ?
Comment 4 Ciaran McCreesh 2005-03-18 08:54:53 UTC
Bad idea. The default setting is fine. People who're giving out shell accounts to people they don't trust can change it themselves.
Comment 5 Ivan Yosifov 2005-03-18 09:32:07 UTC
I agree with Ciaran. IMO it will be best to add a "Security" section to the Handbook which will point the main security elements a user/admin may want to tweak right away. This can include: resource limits, filesystem quotas, basic firewall setup, running services.
Comment 6 Mark Lagace 2005-03-18 09:34:41 UTC
It's not a matter of shell accounts that I am concerned about.  If you give a shell account to someone, then you either trust that person, or set limits.  That being said, various services run as a non-root user for the purpose of increasing security (e.g. the web server runs as user apache).  If there's a vulnerability in that particular application, the attacker would be limited in what they can exploit.  If user apache, or qmail, or nobody, or... can easily crash the system by forkbomb'ing it, that's a problem.

If there's so much concern about 'OH NO, GENTOO is going to make a decision that limits me!', then just set the default limits.conf to something similar to:
* hard nproc 200
@users hard nproc 0

That way, any users that are created have full unfettered access, but services are inherently limited from running amok.  Obviously some 'guestimation' of what constitutes a reasonable default limit needs to be done, but I'm not the person to do so - I just discovered the existance of this file a couple days ago..

At the very least, the gentoo installation handbook should make a note of some of the security concerns of an unmodified limits.conf file.
Comment 7 Wernfried Haas (RETIRED) gentoo-dev 2005-03-18 09:59:38 UTC
Limits are already mentioned in the handbook here: http://www.gentoo.org/doc/en/gentoo-security.xml#doc_chap6

Personally i would like to see sane values in Gentoo's default config even though i know where set it manually as it is just one thing less to care of. Are there any negative effects of a default setting?
Comment 8 Ciaran McCreesh 2005-03-18 10:03:15 UTC
Negative effects: very weird and random behaviour when the limit is hit.
Comment 9 Tavis Ormandy (RETIRED) gentoo-dev 2005-03-18 10:14:13 UTC
Is it possible to define a default that would work on any hardware? 

surely the older the hardware, the smaller limit it would require.

I think we should just leave it as it is, the procedure for changing it is well documented.
Comment 10 Ciaran McCreesh 2005-03-18 10:16:01 UTC
Taviso -- it's not the age of the hardware. It's the number of CPUs. A dual CPU Ultra II will survive far higher loads than any single CPU x86 box.
Comment 11 Tavis Ormandy (RETIRED) gentoo-dev 2005-03-18 10:24:22 UTC
Ciaran: Obviously not literal age, I meant the available resources. I dont think it's number of CPU's that's the problem, it's the memory available to processes.
Comment 12 Ivan Yosifov 2005-03-18 10:28:38 UTC
>>>> Limits are already mentioned in the handbook here: http://www.gentoo.org/doc/en/gentoo-security.xml#doc_chap6

Well... I just found out the existance of this document. I may be blind... or maybe we should stick it in a more obvious place, like in the "Gentoo Handbook".

>>>> Taviso -- it's not the age of the hardware. It's the number of CPUs. A dual CPU Ultra II will survive far higher loads than any single CPU x86 box.

Just an idea. Can't a "sane" default be autogenerated by a script, based on BOGOMIPS and/or CPU count and/or RAM size ? This can be called during install.
Comment 13 Ciaran McCreesh 2005-03-18 10:32:46 UTC
The only 'sane' default is unlimited.
Comment 14 Mark Lagace 2005-03-18 10:43:43 UTC
On the topic of limits being already mentioned, I'm with Ivan on this.  Looking at the Gentoo docs -> Installation related resources (http://www.gentoo.org/doc/en/index.xml?catid=install) there is NO link to the gentoo security guide.

Going through the Gentoo Handbook (at least, the x86 version) there is nothing in the section "Configuring your system" (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=8), nothing in "Finalizing your installation" (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=11), nothing in "Where to go from here" (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=12).

For a new user installing Gentoo, there is nothing to lead them to the security handbook.
Comment 15 Donald Giuliano 2005-03-18 12:55:32 UTC
*Hypothetical Situation*

What happens when Joe User, using a default Gentoo install, happens to run a version of application X which forks ad infinitum when application Y is also running?  Since Joe uses gnome/kde, uses auto-login, and both applications are now stuck in the startup configuration, every time he boots the system it immediately locks up.

Trusting users not to forkbomb a machine doesn't just mean you trust them on an individual basis, as there are many unforeseen things outside anyone's (reasonable amount of) control that you also trust will not happen.  Why should the default configuration be so trusting?  Shouldn't a user/admin be able to trust the security settings of a default installation enough to assume that simply running a program with normal user permissions will NEVER be able to render the system unusable?  Shouldn't this re-configuration burden be placed on those very few that need to run many hundreds or thousands of processes as one user rather than the overwhelming majority that do not?

Just my thoughts on the topic.
Comment 16 Ciaran McCreesh 2005-03-18 13:10:45 UTC
That's a rather, er, far fetched situation...
Comment 17 Wernfried Haas (RETIRED) gentoo-dev 2005-03-18 13:16:22 UTC
In any way a recommendation for a limit like "Setting nproc to foo is usually a good value for a desktop system" either as recommendation in the security guide or as default value (depending on the outcome of this discussion) would be very useful. Otherwise users with a lower level of experience might set it to 10 (one for mozilla, one for xmms, one for kde, still 7 left ;-) ) and only harm their system.
Comment 18 Donald Giuliano 2005-03-18 13:41:22 UTC
I'll grant that that particular situation is pretty unlikely.  However, something uncannily similar to that did happen to a friend of mine recently on his OS X box, so perhaps a situation like that is not as far-fetched as it initially seems.  And yes, he was able to work around the situation without rebooting...
Comment 19 Esben Mose Hansen 2005-03-18 13:58:33 UTC
A normal KDE install creates about 100 processes. I have never seen a single-user system go beyond 400. So setting the limit to 2000 processes should allow enough headroom for any user who doesn't know about ulimit. My box (1CPU, Athlon 64, 1Gb RAM) survived 8000, but froze for a while.

Isn't that a sane, very conservative default? People needing more than 2000 processes would probably know this, and could be alerted in the Gentoo Handbook and friends.

I disagree about the "unpredictable behavior.", BTW.  I tried some absurd ulimits (32 :) ) and all that happened was that nothing worked, and a bunch of messages like "fork() failed: Resource temporarily unavailable. " Certainly no worse than the default "user must belong to wheel to su root" behavior, for one! And that one makes at least as little sense for a single-user, non-server box.

I recommend fixing this bug. 
Comment 20 Tim Weber 2005-03-19 05:21:35 UTC
I say the needs of the many outweigh the needs of the few. Create a sane default limit like the suggested 2000 processes. People with 16 CPUs should be aware that there is something like a limit setting, and so should people with the need to tune their system like hell.

Let's face the facts. Gentoo isn't a distribution for professionals anymore. Every Average Joe tries it out, even if he has no clue of Unix/Linux at all. What would be worse: Disallowing him from running 30,000 processes at once or preventing the possibility of his system going down while he's writing a not-saved-for-3-hours dissertation and "just trying out that strange script my co-worker just sent me"?

There is a sane default setting for gcc's "-j", for Apache's "MaxClients" and certainly a lot of other potentially limiting settings as well. And these are not that important to security like this one.

My suggestion: Put a note somewhere inside the documentation, describing how to disable or change the default limits. Then create a sane default limit. Because we will be saving, or at least securing, far far more users that way than we'll be limiting.
Comment 21 Fredrik Klasson 2005-03-19 06:24:11 UTC
>My suggestion: Put a note somewhere inside the documentation, describing how to
>disable or change the default limits. Then create a sane default limit. Because
>we will be saving, or at least securing, far far more users that way than we'll
>be limiting.
I second that. As mentioned before, forkbombs need not be the intensional deed of some evil entity, but maybe a bug or so.
Maybe make it a note in the "where to go from here", something like "Better safe than sorrow - Read about default security measuerments taken to protect you from (some) mishaps." (_and_ possibly in the sections about the -j option (eg, some thing with pun intended like "don't go crazy with -j31337 - there is a default process limit in /etc/security/limits.conf, read NiftySectionName (URI) in the handbook").
IMO wearing both belts and braces is a good default setup, sure, there are those who'd bully you for wearing that much, but the day someone tries to pull of your and others pants - you'll be the one laughtng ;) [pun intended]
Comment 22 Ciaran McCreesh 2005-03-19 06:26:24 UTC
2000? Heck, you can crash a single CPU box with 200 processes as a normal user. But if you set the limit at 200, KDE stops working.
Comment 23 Esben Mose Hansen 2005-03-19 07:09:49 UTC
Did another set of timings today. 

***************************
* ulimit * Ath64 * Cel300 *
***************************
*  500   *   <2s *   4s   *
* 1000   *    3s *   5s   *
* 2000   *    9s * 126s   *
***************************

Ath64: Athlon 64/1Gb mem/1CPU
Cel300: Celeron 300/256Mb mem/1CPU

None of these tests caused the music to stutter or similar.

I recommend 1000 to protect slower machines, but find 2000 reasonable, though hard on slow/old machines.

The 200 comment above must be something else at work, or a very old machine.
Comment 24 Natanael Copa 2005-03-21 02:46:18 UTC
On my 2.6.11-gentoo-r3 Gentoo box ulimit -u is set to 8187. So there is actulaly a limit.

max user processes            (-u) 8187

However, as far I understood, its only PAM aware applications that is affected by /etc/security/limits.conf. So a deamon in the startup script would not be affected by this? Then I suggest to find another location for setting this value by default.

BTW.. on my Debian stable production server it was set ulimit -u was set to 256!
I haven't found out *where* this value is set in Debian but there is probably the place where this should be set instead of /etc/security/limits.conf
Comment 25 Natanael Copa 2005-03-21 06:53:18 UTC
Created attachment 54058 [details, diff]
fork_bomb_fix.patch

The problem is that the calculation of maximum number of processes is too
generous. The number of maximum process per uid (RLIMIT_NPROC) is calculated
from the amount of RAM. I googled around but I couldn't find how they ended up
with the current formula, but what I know is that it is too generous by
default.

This patch sets it to half of the current default in the kernel and this can
ofcourse be overridden by /etc/security/limits.conf.

By using this patch, there will be no need to touch any of the PAM defaults in
/etc/security/limits.conf.

This should probably be set in the kernel source, but I don't know if I am the
right person to suggest it (or if they are looking into it or not already).
Comment 26 Ivan Yosifov 2005-03-21 07:21:13 UTC
I very seriously doubt the kernel is the place to fix this ! The kernel maximum should be the absolute maximum a system can withstand, it is NOT meant to protect users. If you don't like this limit - there is a file /etc/security/limits.conf for all kinds of tweaking, and policy-setting.
Comment 27 Natanael Copa 2005-03-21 07:39:17 UTC
"The kernel maximum should be the absolute maximum a system can withstand"

Exactly! The problem here is that the "maximum" (RLIMIT_NPROC) is far above the "absolute maximum a system can withstand" - that is why the system dies when you fork bomb it, regardless how much RAM you have.

If you look at the patch (and test it) this should give the following result:

ram     RLIMIT_NPROC
64MiB   256
128MiB  512
256MiB  1024
512MiB  2048
1GiB    4096 

Comment 28 Ivan Yosifov 2005-03-21 07:54:15 UTC
How many proccess a system can withstand depends on a zillion factors. Ram size, CPU count/speed/arch, process activity, and definition of 'withstanding'. If you fork many proccess and only a small set is 'active' - there is no problem. If each proccess forks and forks - this is the fork-bomd, the system dies. If there are 1000 proccess that do extensive computations, the system won't be too up either. 
I am not a kernel expert, but I suspect the RLIMIT_NPROC is used to define the size of some internal kernel structures. Technically speaking , when half the proccess live in the swap, the system is still running correctly, although it is not at all usable. What is the acceptable load is a question an administrator must answer. The kernel must ensure correct operation, nothing more. The kernel source is an awkward place to set policy. It is *wrong*, hard to change, error prone. Why mess with the kernel when there is /etc/security/limits.conf ?
Comment 29 Natanael Copa 2005-03-21 15:09:24 UTC
RLIMIT_NPROC is an offset not an struct/buffer size.

To be honest, I was expecting a convenient way to raise this value. It is possible doing it with ulimit -u after bootup in case someone should run out of processes. I was expecing a sysctl.conf or /proc/sys/kernel interface, but it is missing.

The problem with limits.conf (as far as I understand this) is that the daemons started before login prompt is not affected by this config file. Havent tested that though.

I guess this is the wrong place to discuss kernel internals though...
Comment 30 Natanael Copa 2005-03-22 01:36:35 UTC
Created attachment 54137 [details]
/usr/local/bin/maxproc (test program)

This is a test program. It setuid(nobody), creates new, sleeping processes,
until it cannot create anymore. Number of processes is printed out and all
children are treminated.

Try set your limits (for user nobody) in /etc/security/limits.conf, re-login
and test this prog. it will confirm that limits.conf works at it should. Now,
try run this program from a bootscript. You will see that number of processes
the user nobody can create from boot is above your limit.

Conclusion is that limits.conf does not set limits on the running services and
that is why the maximum allowed processes should be set somewhere else.
Comment 31 Natanael Copa 2005-03-22 01:41:09 UTC
Created attachment 54138 [details]
/etc/init.d/testmaxproc (init script for maxproc.c)

add to default runlevel and reboot. after boot you will see how many processes
the user nobody were able to create in /tmp/maxproc.
Comment 32 Natanael Copa 2005-03-22 01:44:51 UTC
Created attachment 54139 [details]
maxproc.c (test program)

updated invalid comment.
Comment 33 Carsten Lohrke (RETIRED) gentoo-dev 2005-03-22 03:58:35 UTC
*** Bug 86223 has been marked as a duplicate of this bug. ***
Comment 34 Ivan Yosifov 2005-03-22 05:38:07 UTC
This is from 'man 5 limits':
---- CUT ----
Also, please note that all limit settings are set PER LOGIN. They are  not
global,  nor  are they permanent. Perhaps global limits will come, but for
now this will have to do ;)
---- CUT ----

So , indeed limits.conf does not affect init-scripts.

> Conclusion is that limits.conf does not set limits on the running services and
> that is why the maximum allowed processes should be set somewhere else.

Ok, patches are needed. My conclusion , however , is that the patches should go to init. If init enforced the limits, first-thing-after-boot - all is set. Patching user-space init seems much more reasonable than hardcoding limits in the kernel.

Comment 35 Natanael Copa 2005-03-22 06:28:11 UTC
My idea is that the kernel has a sane default, if you have users that need extremely many processes, use ulimit (ideally should limits.conf raise the number of processes per user) and if you have a service that needs extremely many processes, use /etc/sysctl.conf. There is a setting named kernel.threads-max that is somehow related to maximum number of processes. Look at kernel/fork.c and you'll see that init_task.signal->rlim[RLIMIT_NPROC].rlim_max = max_threads/2;

What I found interesting was that the maxproc.c program gave different results when it was run as root and when it was run as normal user. (remove the setuid(UID) and recompile to try yourself) so the patch should only limit the non-root accounts.
Comment 36 Ivan Yosifov 2005-03-22 08:50:30 UTC
>>> My idea is that the kernel has a sane default...

And what is the sane default for a multi-arch kernel like Linux ?

>>> Look at kernel/fork.c and you'll see that 
>>> init_task.signal->rlim[RLIMIT_NPROC].rlim_max = max_threads/2;

This is a hack. thread-max is thread-max.

>>> What I found interesting was that the maxproc.c program gave different 
>>> results when it was run as root and when it was run as normal user.

This looks like a reason.From 'man limits'
---- CUT ----
By  default  no  quotas are imposed on 'root'.
In fact, there is no way to
       impose limits via this procedure to root-equiv accounts (accounts with UID
       0).
---- CUT ----

I think we should be working on the general problem, which is limits not being enforced when they should be, rather on the testcase - how to protect an innocent-user-machine from being forkbombed. I don't know if threadbombing the machine will work, but if it does, do we hardcode a lower thread limit in the kernel ? How about a proccess that: forks a sleeping copy , leaks memory till the OOM kills it , then the copy forks a sleeping copy and starts leaking memory until the OOM kills it... this can be pretty nasty. How about a compromised server that does cat /dev/null > /tmp/file ?
We can't put custom hacks around all these ( like default disk,mem quotas ), and with a limits.conf ( or a default limits.conf ) in place and a 'fixed' init all these can be avoided.
Comment 37 Natanael Copa 2005-03-23 02:15:20 UTC
(Sorry for the wording. This is by no means *my* ideas. This is what they have done long time in other *nixes)

>>> And what is the sane default for a multi-arch kernel like Linux ?

High enough for most apps to work. (think of debian stable has this limit to 256! by default) Low enough so the structures fit in to low mem and finally low enough that a normal user cannot take down the system with a shell fork bomb where other *nixes happily survive, and still high enought for the sytem to boot (currently the low limit is 10 processes)

Take a look what other *nixes does and you'll get an idea what would be a "sane" default.

The limit I suggested was actually in the 2.4.7-ac1. Here is the response why this was done:
http://marc.theaimsgroup.com/?l=linux-kernel&m=99617386529767&w=2

Low mem problem:
http://marc.theaimsgroup.com/?t=100386864300001&r=1&w=2

>>> I think we should be working on the general problem

I understand this. But if you find a problem that affects the security of almost all distros (except those who does ugly hacking to workaround) - and all (most?) other *nixes hande just fine - I believe this is more than just how-do-we-set-the-default-limit-in-our-distro problem.

>>> do we hardcode a lower thread limit in the kernel ?

No. You can raise it with /proc/sys/kernel/threads-max
echo "kernel.threads-max = <set your new limit here>" >> /etc/sysctl.conf

The other examples you mention - for example cat /dev/null > /tmp/file, this will not prevent a syadmin to log in as root, kill the process and remove the file, would it? Same with the fork/memory leak, a sysadmin should be amble to kill a missbehaving process if the kernel does not. In the fork bomb example here, the sysadmin is not able to. That is the problem.

Now, sice nobody seems to care about fix the linux kernel (where I believe the problem actually is) I can suggest another alternative as a temporary "hack":

in /sbin/rc, run ulimit -u <sane default>, before other services are started. I believ Joe User should be able to raise his maximum proc count in limits.conf if needed afterwards.

The problem would be: how to calc the default limit? half the kernel limit? what if an upstream kernel fixes this? I would suggest: take the amount of (low) memory for the system in MiB and multiple with 4. there you have a default that should survive a stupid fork bomb while having more then enough process to play with.
Comment 38 Ivan Yosifov 2005-03-23 06:00:56 UTC
>>> The limit I suggested was actually in the 2.4.7-ac1.

Why did it not get into mainline ?

>>> I believe this is more than just how-do-we-set-the-default-limit-in-our-distro 
>>> problem.

I agree. The PAM-unawareness of init is a problem of all distros. If a patch
is writen for this, it should go into mainline. Any reason not to ?
Besides, the distros that survived the fork-bomb in THAT article, did so because of
limits.conf, not because of custom kernel patches. I won't mind the result of your
formula put in limits.conf, what I say is that it belongs there, not the kernel.

>>> echo "kernel.threads-max = <set your new limit here>" >> /etc/sysctl.conf

Sysctl-s can't replace limits.conf. They lack granularity. There is no way to set the 
limit for a specific user or group by a sysctl. One may want to give a specific 
service a higher limit, not all services.

>>> in /sbin/rc, run ulimit -u <sane default>, before other services are started. 
>>> I believ Joe User should be able to raise his maximum proc count in limits.conf 
>>> if needed afterwards.

Or , in /sbin/rc run ulimit -u <what limits.conf says>
This will have the effect of a *fixed* init. Except that:
	1) It is Gentoo specific	
	2) It won't affect init scipts that don't source /sbin/rc (anyone seen such ?).
	3) It won't work if a service changes UID to Joe.

I don't mind this being done "temporarily" if fixing init will take a long time.

>>> In the fork bomb example here, the sysadmin is not able to. That is the problem.

He is not necessarily able to in the cases I mention, either. 
What if the shell tries to create a temporay file on the full partion 
( or sshd tries to write to the log... ) ? Two days ago I tried loging into a 
mem-leaking box and could not. The machine was swapping like hell and the 
ssh -l root <HOST> just hung.

I don't have anything against a default limit being set in limits.conf. I just want to 
know that: 
	1) It affects everybody
	2) To change a limit I need to change it limits.conf ( not , separately use a sysctl for daemons )
	   
This conventions seem common-sense to me and less confusing to user and sysadmin alike.
Comment 39 Natanael Copa 2005-03-23 08:52:45 UTC
>>> Why did it not get into mainline ?

I don't know. I couldn't find anything about it in the kernel mailing list.

A wild guess would be that someone complains about a failing benchmark.
http://marc.theaimsgroup.com/?l=linux-kernel&m=99616958413691&w=2

>>> Sysctl-s can't replace limits.conf.
Agree. but it could complement for daemons that are not aware of PAM.

>>> Or , in /sbin/rc run ulimit -u <what limits.conf says>
I kind of liked this, but will it work for non PAM aware daemons?

>>> 2) It won't affect init scipts that don't source /sbin/rc (anyone seen such?).

I dont really understand this. /sbin/rc is called by init, specified in /etc/inittab

>>> 3) It won't work if a service changes UID to Joe.

Could you please explain this?

>>> What if the shell tries to create a temporay file on the full partion 
>>> ( or sshd tries to write to the log... ) ?

Thats why you should have a separate /tmp and /var partitions and run logrotate etc. (interestingly enough, the default "automatic" partitioning in freebsd creates a small /tmp)

I believe something like this might work (calculate a "sane" default and let a sysadmin overide by defining @daemon in /etc/security/limits.conf for the bootup scripts)

--- rc.orig     2005-03-23 17:40:48.763435938 +0100
+++ rc  2005-03-23 17:47:04.459883746 +0100
@@ -168,6 +168,11 @@
        # Note: /proc MUST be mounted
        [ -f /sbin/livecd-functions.sh ] && livecd_read_commandline

+       # set default maximum user processes
+       ulimit -u $(calculate_max_user_processes)
+       daemon_nproc=$(awk '/^@daemon/ { print $4}' /etc/security/limits.conf)
+       [ -z "${daemon_nproc}" ] || ulimit -u ${daemon_nproc}
+
        if [ "$(get_KV)" -ge "$(KV_to_int '2.6.0')" ]
        then
                if [ -d /sys ]
Comment 40 Ivan Yosifov 2005-03-24 04:26:31 UTC
>>> I dont really understand this. /sbin/rc is called by init, 
>>> specified in /etc/inittab

Nevermind. I mistook it for something else. Looking at /etc/inittab it seems all init 
script are actually called from /sbin/rc, so calling ulimit there will have the exactly
same effect as patching init. This is Gentoo specific, but may not be such a bad idea
as it is a lot simpler , IMO , than messing with init.

>>> >>> Or , in /sbin/rc run ulimit -u <what limits.conf says>
>>> I kind of liked this, but will it work for non PAM aware daemons?

Check out 1) man 2 setrlimit
	  2) info libc -> Resource Usage And Limitation -> Limits on Resources

This is from 2) :
---- CUT ----
Each process initially inherits its limit values from its parent, but it can
subsequently change them.
---- CUT ----
( Can change them, if priviliged. User Bob can not. )

So if the parent called ulimit , it will affect the child, PAM-aware or not.

>>> >>> 3) It won't work if a service changes UID to Joe.
>>> Could you please explain this? 

Sorry for the wording. What I meant is that if a PAM-unaware service changes persona to
user Bob, it will still use the limit it inherited from the parent, not Bobs limit.
Actually, I don't think there is any way around this except fixing the service. Note, 
that if the service uses su ( and not setuid directly ), su is PAM-aware and Bob's 
limits will be set.

>>> I believe something like this might work (calculate a "sane" default and let a 
>>> sysadmin overide by defining @daemon in /etc/security/limits.conf 
>>> for the bootup scripts)

I like this. @daemon will serve as a daemon default. If the admin wants to give a PAM
aware service more playground he can increase the limit for the service user ( any 
services running as root left around ? ).
If the admin wants to give a PAM-unaware service more playground we can call ulimit in
the init script.
Comment 41 Natanael Copa 2005-03-25 00:02:56 UTC
>>> ( Can change them, if priviliged. User Bob can not. )

I think User Bob can change them, just not raise them.

>>> I like this. @daemon will serve as a daemon default. If the admin wants to
>>> give a PAM aware service more playground he can increase the limit for the
>>> service user

I would actually like to set a default limit as early as possible (preferrible in the kernel). Things that starts very early would not be affected (like udevd)

>>> ( any services running as root left around ? ).

inetd, xinetd, ntpd, sendmail?

This would be another reason to not run a service as root.

>>> If the admin wants to give a PAM-unaware service more playground we can call
>>> ulimit in the init script.

We could actually make a function/app that parses limits.conf and set the limits for the specified user/group. You could call it from your init script.

set_limit ${USER}:${GROUP}

BTW... is start-stop-daemon PAM-aware? We could patch start-stop-daemon so that if -c is used it parses /etc/security/limits.conf and runs setrlimit() before chainging uid:gid.

At the end, the user could tweak limits for any daemon from /etc/security/limits.conf.

The only bad thing is that if a Gentoo admin runs other distros he/she would think that his box is secure after tweaking /etc/security/limits.conf. So this would be Gentoo-specific. Thats the drawback.
Comment 42 Ivan Yosifov 2005-03-25 06:06:18 UTC
>>> I think User Bob can change them, just not raise them.
Correct.

>>> I would actually like to set a default limit as early as possible 
>>> (preferrible in the kernel). Things that starts very early would not be 
>>> affected (like udevd)

Is udevd started from init ? If so, why should it not be affected ?

>>> >>> ( any services running as root left around ? ).
>>> inetd, xinetd, ntpd, sendmail?

Are programs running as root affected by setrlimit ? I could not find anything in the manpage.

>>> BTW... is start-stop-daemon PAM-aware?

I don't know. Can some baselayout dev comment on this ?

>>> So this would be Gentoo-specific. Thats the drawback.

If we move the /sbin/rc hackery into init, and it is accepted upstream, it will not
be Gentoo-specific.
Comment 43 Sascha Silbe 2005-03-27 09:42:17 UTC
Please also note the difference between hard and soft limits:
Any user can change the soft limit (that's the one being enforced), but only up to the hard limit.
Any user can lower the hard limit.
Root can also raise the hard limit.
Comment 44 Natanael Copa 2005-03-28 00:41:03 UTC
>>> Is udevd started from init ? If so, why should it not be affected ?

I was thinking of early in /sbin/rc

>>> Are programs running as root affected by setrlimit ?

No.

>>> >>> BTW... is start-stop-daemon PAM-aware?

>>> I don't know. Can some baselayout dev comment on this ?

If not, we could batch it. Call setrlimit if -c is specified.

>>> If we move the /sbin/rc hackery into init, and it is accepted upstream, it will not
>>> be Gentoo-specific.

I actually dont understand why you want it in init. (unless you want default limits per runlevel)

Don't they use init on other *nixes? The too high-defaults is a Linux specific problem.

Comment 45 Natanael Copa 2005-03-28 00:42:49 UTC
>>> Any user can change the soft limit (that's the one being enforced), but only up to the hard limit.

That's why only hard limits are useful in a security perspective.
Comment 46 Ivan Yosifov 2005-03-28 02:37:35 UTC
>>> I was thinking of early in /sbin/rc

We can call the limit stuff before that.

>>> >>> Are programs running as root affected by setrlimit ?
>>> No.

Bad. Any way to limit a root process apart from the sysctl-stuff ?

>>> >>> >>> BTW... is start-stop-daemon PAM-aware?
>>> >>> I don't know. Can some baselayout dev comment on this ?
>>> If not, we could batch it. Call setrlimit if -c is specified.

If we choose to patch it, I really think -c should be used by default.

>>> I actually dont understand why you want it in init. 
>>> (unless you want default limits per runlevel)

Limits are inherited from parent process. Init is the root of the process tree. That's
the only reason. Any other way to set a limit for all processes ?
Comment 47 Natanael Copa 2005-03-28 03:24:31 UTC
>>> Bad. Any way to limit a root process apart from the sysctl-stuff ?

I don't think even sysctl stuff limits root. I don't think you can limit root at all.

>>> >>> If not, we could batch it. Call setrlimit if -c is specified.
                         ^^^^^
("batch it"... good morning...)

>>> If we choose to patch it, I really think -c should be used by default.

I think we could use a low default limit (called from early /sbin/rc or patch kernel), thos sservices that uses "start-stop-daemon -c" could be controlled by /etc/security/limits.conf. The other ones would be limited by the default.

>>> Limits are inherited from parent process. Init is the root of the process tree. That's
>>> the only reason. Any other way to set a limit for all processes ?

Patch kernel, initrd, /sbin/rc

/sbin/rc is actually called directly by init so all services would be affected by a ulimit -u from here. The logins are controlled from limits.conf.

Comment 48 Ivan Yosifov 2005-03-28 04:10:28 UTC
>>> I don't think even sysctl stuff limits root. 
>>> I don't think you can limit root at all.

Does "at all" include patching the kernel ( thought using the sysctl and patching the
kernel are equivalent ) ? If you can't limit root, isn't a PAM aware start-stop-daemon
all we can do for services ?

>>> ("batch it"... good morning...)

It is morning. English is my second language. I understand that you want 
start-stop-daemon to act PAM aware only if -c is passed. I say this should not be 
optional.

Users are already limited by limits.conf. A PAM-aware start-stop-daemon will limit 
services not running as root. A ulimit <some default> in /sbin/rc will place an 
overrideable default on all non-root apps. 

What exactly do I do the initrd,kernel,/sbin/rc to affect root ?
Comment 49 Thierry Carrez (RETIRED) gentoo-dev 2005-03-28 05:00:55 UTC
The position of the Gentoo Security Team on secure-by-default is the following :

Security is a tradeoff. Here you have to balance the impact with the lost functionality. The impact here is a Local DoS on systems hosting multiple users that would use an unmodified default configuration. The tradeoff being setting a default arbitrary upper limit to the available computing power on all systems.

Here our position is that the impact is not worth the tradeoff. Gentoo users running multi-user systems should have a clue. And if they don't, the first Local DoS they run into should get them the clue. We are not talking Local Root here. The impact is limited. And if the system is a default-configured mission-critical one, then that user has a problem anyway. Keeping a system safe from Local DoS is not an easy task anyway, a sane default limits.conf is not their biggest problem.

So we'll not require this default configuration option into baselayout in the name of security. That doesn't mean it's not a good idea, just that we won't pressure the baselayout guys to include it in the name of security. If most other Linux distributions did ship the same default limits.conf file, others could require it under the "users are expecting it to be there" name. But that's not the case AFAICT.

So reassigning to Baselayout guys as an enhancement request.
Comment 50 Natanael Copa 2005-03-28 05:37:21 UTC
This was interesting.

Whats the "lost functionality" in lowering the default maximum number of processes for the non root users?

>>> Gentoo users running multi-user systems should have a clue. And if they don't, the first Local DoS they run into should get them the clue.

What about the opposite? Set low limit as default, those who meet problems - let them find out how to raise the limits. (If you *need* 4000 processes or more then I bet you have have a clue what you are doing anyway)

About comparing Gentoo with "most other distros" is also interesting because this is a problem on most distros - if you compare to other *nixes (like BSD).

I have tried to bring attention to this in linux-kernel but they don't seem to care there either.

Thanks for your attention anyway.
Comment 51 Wernfried Haas (RETIRED) gentoo-dev 2005-03-28 07:46:07 UTC
> So reassigning to Baselayout guys as an enhancement request.

Smart move if you don't want to be the one being in trouble because there will always be people opposed to which outcome there will be. ;-)

I still think that more people would like to see a sane limit as a potential DoS does affect every box. Forkbombs do not only affect people giving accounts to random people they hardly know. I'll rather have potentially weird effects when reaching the sane limit than having my box completely locked up.

If the baselayout team still decides to do nothing about it, please improve at least the docs (comment 14).
Comment 53 Wernfried Haas (RETIRED) gentoo-dev 2005-03-28 09:30:02 UTC
> The docs have already been improved.

good to hear that :-)
Comment 54 Ciaran McCreesh 2005-03-28 09:34:45 UTC
OK, if it's in the docs then this can definitely be closed as WONTFIX.
Comment 55 spiritus 2007-04-03 20:08:39 UTC
(In reply to comment #54)
> OK, if it's in the docs then this can definitely be closed as WONTFIX.
> 

Any malicious user with the local access could kill a server launching forkbomb PHP script. Nor /etc/security/limits.conf, nor RLimitNPROC in httpd.conf wouldn't help because apache is daemon without PAM support(pam_limits.so) and RLimitNPROC doesn't limit resources for apache itself and mod_php. 
It would be nice if /etc/security/limits.conf could restrict all users and daemons(like in FreeBSD), and not only daemons that has a PAM support.
Comment 56 Tristan Heaven (RETIRED) gentoo-dev 2007-04-26 02:06:32 UTC
*** Bug 176059 has been marked as a duplicate of this bug. ***
Comment 57 SpanKY gentoo-dev 2007-07-23 02:26:51 UTC
"local user" generally implies login, not the ability to upload a php file for apache to execute.  however, php itself has resource restriction that is enabled by default (like memory limits).