No forkbomb protection by default !?!

[nat]

I would like to remind you that setting the limits in /etc/security/limits.conf does not limit the daemons started from bootscripts, even if they are running as non-root. So an attacker that explioted a buggy service will still be able to forkbomb you system.

Try yourself by setting your limits.conf and run this program from a bootscript:
http://bugs.gentoo.org/attachment.cgi?id=54139

(the program just forks til limit is reached, number of forks is printed and children terminated)

[DrSpirograph]

Many people on this thread (and on /.'s thread) are always thinking "if you give someone else a shell access, then you know how to of limit his access".

That's somewhat stupid. Look at the number of threads on the "Networking & Security" forum on which hackers can get shell access but are unable to get root access.<snip>

Even stupider is the assumption that everyone giving out shell access knows that process limits should (or even can) be imposed.
I have been administering linux boxes for about 4 years now. 3 at home, 2 at work. I've tinkered with them considerably but still do not consider them secure, and reading the Security Focus article only confirmed this, as it was the first I'd heard of my systems being vulnerable to a fork bomb - or that I even had the power to set process limits for users.
Does this make me:
a) An incompetent administrator.
b) An administrator who's done the best he can to secure his boxes, but doesn't have time to trawl through every piece of documentation for every single installed package?

On the other hand if limits were in place by default, my (and many others boxes) would be protected, and even if the limits were too low, it would only take me a quick google to figure out the problem and how to fix it. As opposed to having no limits and being completely oblivious of their absence.

I don't understand why people are against reducing the limit to something sensible and noting it in the documentation because it's inconvenient. This is an inconvenience for only a small subset of users, the rest will not notice.
On the other hand there is a far worse inconvenience in the current Gentoo install that all those who need convenience are over looking - by default there is no root password set!! *gasp* That's right, you have to set a password for the root account every single time you install gentoo, otherwise you'll be locked out when you reboot. How inconvenient!

[schleyfox]

I have an idea, just mention it in the install. You preserve choice while alerting people to it, everyone wins.

[steveb]

I have an idea, just mention it in the install. You preserve choice while alerting people to it, everyone wins.

But this kind of info is already mentioned in the security section of the documentation. Why mirroring that info again and again?

cheers

SteveB

[Sqeaky]

I think that everything should be secure by default. A busy system administrator may either not know, and/or have time to check into the prevention of miscellanious DoS attacks. This seems like a such a basic security concern that it perplexes me that it was not set. Nat already posted one example of how this could be dealt with in a fashion that worked for the vast majority of users. Debian apparently has solution also. Implenting this should be a non-issue as far as debate is concermed, even the technical side of it seems fairly trivial.

Secure By default, open it if you want it open. That is how the rest of linux security seems to be set in place, this should be no different.


[edit- this was added]

On the last page of the install document Security is mentioned right after changing the root password. We (Gentoo community) may want to consider bringing security more up front, a link could be added in the working with gentoo section of the gentoo handbook.

Note that I am not trying to say anything derogitory about anyone, I actually think that the gentoo developers do quite a good job with security. I frequently get reports from secunia about gentooers having fixed a security bug before I get the actual announcement of the bugs discovery.

[converter]

this is like saying Gentoo should be secure by default from infinite recursion...

Infinite recursion is a bug that will always lead to a Denial of Service condition. Can you think of any valid reason not to protect your system from the effects of an error that makes both the program in which it occurs and the entire system useless?

Since this issue began to receive so much attention a few days ago, I've been experimenting with limits on my personal workstation, an Athlon 2800+ with 512 meg running x.org and KDE. I've found that the following settings work well most of the time:

Code: Select all

@users          -       maxlogins       16            # i often keep several xterms open, as well as console sessions
@users          hard    core            1000
@users          hard    fsize           819200      # i have to create large files.
@users          hard    cpu             40              # if it weren't for quake3 i could probably make this much lower
@users          hard    nproc           256           # lots of slack here, need to bump this down some more
@users          hard    nofile          2048
@users          soft    stack           8192
@users          hard    stack           32768
@users          hard    data            393216
@users          hard    as              786432

The stack and nproc settings can help with forkbombs, if I understand the situation correctly.
I've noticed that with these settings, if I drop into a console and run

Code: Select all

$ perl -e 'fork while 1'

within a few seconds it becomes impossible to log in via console, but the system remains responsive and the forkbomb perl parent can be killed with keyboard INT. Without limits, it takes only a few seconds for the system to become unresponsive, requiring a reset to regain control.

I'm guessing that after nproc is exceeded, attempts to fork are failing with EAGAIN, and that's what is keeping the system responsive. I doubt that cpu is coming into play here until later, since it's set high enough to allow quake3 to hog the system for at least an hour.

I'm still not certain of the cpu limit and how the system calculates the cpu time for a process. I'm assuming it's a measurement of the percentage of cpu time used by a process over a period of time.

I think it would be great if someone who knows his stuff with regard to rlimits would write up a gentoo guide. Perhaps a sticky thread comparing systems and working limits settings would be helpful, too.

As far as some sensible set of limits goes, perhaps one of the system ebuilds could advise the user to read some helpful information about the subject online and to copy one of a handful of default limits.conf files to the /etc/security directory. This would make users aware of a potential security/availability problem and give them an opportunity to do something about it without imposing potentially problematic, arbitrary limits.

[converter]

I found out that the /etc/security/limits.conf is only affecting pam-aware applications. So I guess a sane default value should be set somewhere else but I have not idea where. I have not found out where Debian gets their max user processes = 256 from, but I think that it should be set to something like 2048 or even 1024.

If anyone get problems of this (I doubt anyone would - maybe 32 CPU systems....) there could be some lines in the install docs telling how to set this (for example in /etc/initscript or /etc/security/limits.conf)

Now I need to find out where this is set. (its obviously not in /etc/security/limits.conf)

I think you want /etc/limits.

Mine looks like this:

Code: Select all

root -
* L16 A786432 D393216 S32768 U256 N2048 F819200 C1000 T40

I agree, as I stated above, that we need a "Limits Guide".

As for the setting for maximum number of processes, I guessed mine with

Code: Select all

$ ps u -U <userid> | grep -c .
50

from an xterm while running a normally-loaded KDE setup, and doubled it to
accommodate extra applications and the number of extra processes required
when starting an instance of bash with completion, which runs a lot of processes
before it prints the prompt. Over a period of time, I increased the limit to 256
and found that it was enough to keep the system responsive under a forkbomb,
which was my primary goal.

I should probably give root some limits as well, but I'm mainly concerned
with protecting myself from my own stupidity at the moment.

[nat]

They decided to not do anything about it.
http://bugs.gentoo.org/show_bug.cgi?id=85656#c49

[lkarayan]

They decided to not do anything about it.
http://bugs.gentoo.org/show_bug.cgi?id=85656#c49

I thought this route was so unbelivably wrong, that I decided to create an account just to voice my opinion.

There should absolutely be limits on the # of processes, and people with more esoteric needs could change them to something higher, or unlimited.

If sombody writes faulty software in their account, I would rather have them have unexpected results, than to have my work interrupted, and the system brought down.

The people that need something more than 1000s of processes per user, should have enough knowledge to increase the limits, but the users that casually install Gentoo to try it out might not know about it.

This could be alleviated if there was a prompt with a suitable recommendation late in the installation process, but it should have a reasonable recommendation, and it can serve as a reminder to power-users.

While I'm not condoning lowest common denominator, I am saying that the needs of the few shouldn't outweigh the needs of most. Especially when those needs can be met by tweaking the kernal later (or if it ever moves to /proc which would be better)

[AngelKnight]

Someone convince Linus to put policy code in-kernel. If he does, then I'll deal with it. Until then, I'll remember to set ulimits for shell users on my own.

Folks, there are *plenty* of Unix system administration books out there. Gentoo is not out to teach you these things; the learning is your responsibility.

*nix isn't for folks who want an easy computer.

My 2c. Bye now.

[Sqeaky]

*nix isn't for folks who want an easy computer.

This doesn't mean that that there shouldn't be sane defaults,

Debian, and the BSD's are *nix and they have a solution for the problem

[edit]

What says the default limits have to be static, they could be calculated during the install process or during boot to something that is near the limits of the system, but still prevents a fork bomb from causing nonresponsivness

[Mad_Jester]

I have been a *nix administrator for a number of years now, and I try to keep security foremost in my concerns as I plan, build, and administer my systems. I use firewalls, encryption, monitors, chroot jails, application security, etc. to try and keep my systems secure. Because I think that I keep a close eye on security I was suprised to see that my Gentoo servers (15 of my servers are Gentoo) were vulnerable to an old unsophisticated forkbomb.

I think that people who are claiming that if you add shell users you can't trust you should know enough to change the limits.conf yourself, are missing the point. The original incident that spawned the article, that has us all talking, was not caused by an authorized shell user. It was the result of a hacker claiming he could forkbomb a system he had compromised via an awstats vulnerability. He was not an authorized shell user, he was using a reverse shell as the apache user.

I agree that *nix isn't for everyone. I think that is a given. However, even the most experienced admin can and will overlook things. That is why we have defaults. I think not having "sensible" defaults here is an oversight. The defaults can be set quite high. High enough to avoid ever becoming an issue for virtually anyone. In the case of Gentoo we are looking at unlimited resource access for anyone who can get any access to the system. I have setup and administered a number of Debian boxes in different environments and I have never had an issue with their defaults, nor for that matter has anyone else I have ever dealt with (it's not like the Debian mailing lists are flooded with problems from it).

The bottom line is that reasonable limits won't interfere with anything but the most extreme circumstances, and would still be enough to stop a forkbomb attack on most systems.

I am not going to pretend to know what would be reasonable for the distribution, but I would really like to see someone post some examples. The documentation for /etc/limits and /etc/security/limits.conf are both relatively sparse and without guidelines it would be difficult for someone to come up with their own settings. I have had mine set pretty low without trouble, but I am sure that I could increase them and still protect myself from a local DoS attack. I think that kind of information would help those who are aware of the problem, but don't know what to do about it.

[Spockmeat]

I'm sorry, I also can't see a reason not to limit user processes by default. Can anyone state a single reason why over say 5000 user processes would ever be needed? I mean seriously, its like including netfilter in the kernel and then setting the iptables rules to allow all traffic. I've been using linux for 5 years and I've never even heard that this could be a problem. Honestly, who would expect an attack as old as a fork bomb to still be a threat.

And I looked through the gentoo security, there's one little section that doesn't explain anything about user limitations. It give an example of some numbers you could use and moves on to the next section.

[Sqeaky]

If gentoo were vulnerable to the land attack (A forged packet with sender and reciever set to the same address, this crashes crappy tcp/ip stacks) would we fix it or would we says that any good sys admin should filter packets at the perimeter. I am pretty sure that we would fix it, because its easy to check for, and makes the system more secure and more usable. I have never heard of either of these kinds of limits causing problems.

In my opinion a system that crashes less is more usable.

Also, windows has some protection against similiar attacks, I made a program that opens infinite instances of notepad, and it stopped creating more at about 250, I lost count, but the system did continue to respond. Shouldn't our defaults be atleast as good as windows.
BTW it was an NT4 machine, and I am not sure if was default or not, but still if windows can do it, we can do it better.

[nat]

Someone convince Linus to put policy code in-kernel.

Linus should at least have better defaults (like the BSD's) and let those who needs more processes raise the limits. (its easy)

I have tried on the linux-kernel list http://marc.theaimsgroup.com/?t=111137472900001&r=1&w=2 but nobody seems to care really.

*nix isn't for folks who want an easy computer.

You should take a look at OSX.

btw... even OSX handles this better than Linux by default.

[lkarayan]

Someone convince Linus to put policy code in-kernel. If he does, then I'll deal with it. Until then, I'll remember to set ulimits for shell users on my own.

Folks, there are *plenty* of Unix system administration books out there. Gentoo is not out to teach you these things; the learning is your responsibility.

*nix isn't for folks who want an easy computer.

My 2c. Bye now.

Right, so if you want extreme limits, then set them yourself. In the mean time, we avoid bad press, crashing machines, an elitist sterotypes.

[lkarayan]

What says the default limits have to be static, they could be calculated during the install process or during boot to something that is near the limits of the system, but still prevents a fork bomb from causing nonresponsivness

This would definatley be the best route with the ability to override the defaults to more or less to suit the needs of the admin.

[steveb]

This would definatley be the best route with the ability to override the defaults to more or less to suit the needs of the admin.

I would not like that! If I could wish, then I would like something like limits-config (like the java-config, gcc-config, mirror-select, ufed, etc). But something which is calculated at install time, without me knowing what exactly is calculated, would irritate me. What next? A tool that automaticly does the partitioning for me?
Please no! To much automatic stuff is not the way to go. Tools are okay, but I want to be in charge of the changes.

cheers

SteveB

[Sqeaky]

A possible solution could calculate the limits by default at install time (or base the limit off an enviroment variable), but still put the limit(or appropriate variable) in the file. This way, if someone did want to change it, they could remove the autogenerated entry.

[someguy]

I know that it's easy to fix this problem.

The fact is that this part of Gentoo is not secured by default!! Is there any good reason to not secure this by default?? Confused

This remembers some other OS... What's its name again?? Win.... Windows??

isnt gentoo supposed to be setup the way you want it to be setup do it yourself and it should fix the prob they probably didnt have the system setup right

[nat]

But something which is calculated at install time, without me knowing what exactly is calculated, would irritate me.

Did you know that your current default maximum number of processes is calculated from the amount of RAM at boot-time?

[befortin]

I also think that a tool [script] to "secure" a system's ulimit (and a reference to this tool in the Gentoo Security documentation) would be a nice solution.

[lkarayan]

This would definatley be the best route with the ability to override the defaults to more or less to suit the needs of the admin.

I would not like that! If I could wish, then I would like something like limits-config (like the java-config, gcc-config, mirror-select, ufed, etc). But something which is calculated at install time, without me knowing what exactly is calculated, would irritate me. What next? A tool that automaticly does the partitioning for me?
Please no! To much automatic stuff is not the way to go. Tools are okay, but I want to be in charge of the changes.

cheers

SteveB

The limits are already calculated within the kernel, the override was my request.

[befortin]

They are calculated in the kernel, but those are not realistic limits. I have a limit of 8192 user processes with 512 MB of RAM (!)

Anyway, if some devs think that it's OK (or even nice!) that, on a default Gentoo system, any regular user can DoS a system using such a stupid DoS attack... I find this quite frustrating, but I can't do anything about it. I see no good reason not to fix this problem.

[nat]

I have seen several suggestions to fix this in the kernel mailing list. At least they are aware about it and they do try to fix it. (and yes, the kernel is the place where this should be fixed)

I see light at the end of this tunnel...