# No forkbomb protection by default !?!

## befortin

There's an interesting article on SecurityFocus about Linux Kernel Security.

Here's an interesting quote : 

 *Quote:*   

> Both Gentoo and Red Hat followed in the footsteps of Mandrake, and each died quicker than you can say "unreasonable default settings."

 

While the columnist is talking more specifically of Linux Kernel Security, but there are some config that could (and SHOULD, IMHO) be set by default on Gentoo to prevent forkbomb...

Any thought about this??

----------

## lopez

Check out Section #6  User/group limitations

```
http://www.gentoo.org/doc/en/gentoo-security.xml
```

```
Code Listing 6.1: /etc/security/limits.conf

*    soft core 0

*    hard core 0

*    hard nproc 15

*    hard rss 10000

*    -    maxlogins 2

@dev hard core 100000

@dev soft nproc 20

@dev hard nproc 35

@dev -    maxlogins 10

```

You can set max processes users are allowed to run and other settings.  

By default it doesn't set limits. But its easy to tweak for your preferences 

after you get your system up and running. 

Hope this helps.

----------

## befortin

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??

----------

## lopez

I guess its more of a design issue and how the distribution as a whole is released.  Some developers might not want these restrictions on a release as they want to bring the box to its knees for testing purposes.  Others strive for security and everything locked down as tight as can be.  I guess it comes down to a release philosophy how is the final product presented. ?

----------

## Jake

 *befortin wrote:*   

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

 

The system crashing isn't a security issue. What is a security issue is if someone has enough access to your desktop to run a fork bomb. Anyone running a Gentoo-based shell server should know to secure the machine.

----------

## befortin

If this is about a release philosophy, it does sounds like the good old release philosophy from Microsoft and Red Hat : close and patch all those unsecure things that you want to secure.

Like Jason Milled, from SecurityFocus, said in its article : 

 *Quote:*   

> Even though a local user should be somewhat trusted, that doesn't mean you should hand them a silver platter with the ability to take down the entire machine. This attitude that there is any one panacea really bothers me.

 

and

 *Quote:*   

> I personally don't understand how usability can supersede security when the consequences are so grave.

 

----------

## befortin

 *Quote:*   

> The system crashing isn't a security issue.

 

OMG!! The system crashing isn't a security issue!!??

Do you really think that its a good idea that, by default, a "normal" user can crash a system that he has access to?

 *Quote:*   

> Anyone running a Gentoo-based shell server should know to secure the machine.

 

Why should we include any security in a system by default? "Anyone who runs a server should be able to secure it", right??

OMG!!

----------

## mark_lagace

I filed a bug report on this.  With any luck something will be done.

----------

## Jake

 *befortin wrote:*   

> OMG!! The system crashing isn't a security issue!!??
> 
> Do you really think that its a good idea that, by default, a "normal" user can crash a system that he has access to?

 

If it's Gentoo, yes. I don't want to be bogged down by process, login, or memory limits. I want to be able to crash my system. If I'm not the only user logged in, there's something very wrong.

 *befortin wrote:*   

> Why should we include any security in a system by default? "Anyone who runs a server should be able to secure it", right??
> 
> OMG!!

 

Gentoo should include only security that don't inconvenience the user too much. I'm a big fan of OpenBSD, but Gentoo doesn't need to follow the same path. All that security comes at price. OpenBSD maintains a very high level of usability considering the security they implement. If Gentoo attempted something similar, things would break all the time. That's why we aren't all using the hardened profile by default.

----------

## befortin

 *Quote:*   

> I want to be able to crash my system.

 

Really? Gentoo is, IMHO, one of the most serious and regarded distros out there. I don't think that the ability to crash your system is what most users are looking for.

 *Quote:*   

> If I'm not the only user logged in, there's something very wrong.

 

Isn't Linux a multi-user OS? Gentoo isn't only used as a desktop OS.

 *Quote:*   

> Gentoo should include only security that don't inconvenience the user too much.

 

Would a "max number of processes a user can run" really "inconcenience the user too much"? I don't see how it would. If the maximum number of processes would be set so that it doesn't cause any problem to 99.999% of Gentoo users, it would be just nice IMHO.

----------

## d_m

I agree with befortin. I think for someone who walks through all the documentation on installing and setting up their system the expectation is "I haven't enabled all the flashy, new, crazy or risky things (bootsplash, ~x86, pure udev, etc.) but I do have a system that is in a good, secure default state. 

Gentoo already does a similar thing with services: almost everyone wants sshd running, but I don't think anyone thinks it should be turned on by default. The best philosophy towards services is "start with none and let the user/admin choose which they want." I think similar attitudes with resouce limits, permissions, etc. make the same amount of sense.

I would rather that a developer or use who is doing something special and wants resource limits gone be the one to have to make a change. Like people have said, its the people who don't even realize that these limits aren't set (like inexperienced Windows/RedHat admins) who are going to get screwed under the current system.

Gentoo is about choice, but the choice in this case should be to make an insecure change, not to have to enable security.

EDIT: to clarify what I mean: rewriting tools or totally changing interfaces (like OpenBSD) isn't necessarily what Gentoo needs to do, but if there are standard or easily overridden things that can be done for security, they should IMO.

RE-EDIT: also, for the record, I'm running Gentoo on a multi-user server. There aren't many users, and I'm not sure any of them would know how to trash the system, but I'd like to think that desktop users (specifically developers) aren't the only ones the default setup is geared towards.

----------

## befortin

Nice, someone agrees  :Smile: 

I agree that Gentoo isn't about securing everything as much as possible in the default installation (OpenBSD takes care of this). But still, it should (and it almost always does) provide somewhat secure default settings.

For example, when you install Samba, it doesn't share / with anonymous access allowed by default. And when you install NFS, root_squash is disabled by default for the same reason.

----------

## 59729

I agree to it should be secured as default, the user can always change it after if it is limiting things

----------

## digital_

My 2 cents, put a mention of this in the install documentation and let the individual user decide.

I personally have zero need for process limits. Some people will, document it for them.

I don't view gentoo as a general-purpose distro (although it can be configured to be) and as such this is not something that should be a default. Before I get flamed, what I mean by general-purpose distro is one that is ready to run right off-the-shelf, like redhat or suse. There is an expectation in those distros that the system is ready for general use the minute it is installed. Gentoo isn't that type of system, the minute gentoo is installed (at least stage1) there is no X or any running services.

Gentoo is about customization not off-the-shelf ready to run. Flexibility comes at a price. Document this, let people decide what they want.

PS I personally choose to run gentoo as a general-purpose distro (using my own definition) but I rarely recommend it as such to others. The kind of people who would be happy with gentoo as a desktop system are my friends who are already running it.

----------

## befortin

I still wonder why someone would need to run an infinite number of processes...

Flexibility comes at a price, so does security. I think that it would be reasonable (on both the security and the usability sides) to limit the maximum number of processes that a user can run at a very high value and document it into the Gentoo doc...

----------

## beandog

 *befortin wrote:*   

> Nice, someone agrees 
> 
> I agree that Gentoo isn't about securing everything as much as possible in the default installation (OpenBSD takes care of this). But still, it should (and it almost always does) provide somewhat secure default settings.
> 
> For example, when you install Samba, it doesn't share / with anonymous access allowed by default. And when you install NFS, root_squash is disabled by default for the same reason.

 

Now  you're talking about two *completely* different things (you first stared talking only about the kernel).

The Gentoo security dev team should not be responsible for checking every package (popular as samba or not) to see how locked down the settings are.  There just aren't enough developers to go around to see that everything is shut down tight by default.

----------

## d_m

 *digital_ wrote:*   

> My 2 cents, put a mention of this in the install documentation and let the individual user decide.

 

That would be fine.

Setting stuff up by hand is how a Gentoo install works; IMO limits are something most people should consider. Even on a single-user machine, having berserk processes each up all your resources is no fun. For anyone who hasn't had berserk processes fill up /tmp, etc., it's definitely no fun.

Now that I think about it, what would probably be the best solution would be for an additional guide to exist (post-install) similar to the Gentoo Desktop guide that is specifically aimed at multi-user systems. There are a lot of specific guides (home router, virtual mailhosting, dns, etc.) but having a basic guide would be really useful. There would probabyl be some overlap with the Gentoo security guide, but it could be more like the install doc (setting up reasonable defaults rather than just giving you ideas). For instance:

1. user quotas, process-limits, etc.

2. iptables rules aimed at servers (i.e. no IP forwarding/masquerading, more emphasis on opening up services securely)

3. advice on partitionaing, and how to mount partitions (maybe could be linked to from the install doc)

4. step-by-step instructions on using su/sudo

5. step-by-step instructions on setting up a particular logger and logfiles.

6. a list of what services you might want and which (major) packages provide them.

7. example (or link to) how to write a simple init script (cause people often need them and do it wrong)

Anyway, I think something like that, linked to from the install guide ,would pretty much cover it from my point of view. I may try to work on it but documentation isn't always my strong suit  :Wink: 

----------

## d_m

 *beandog wrote:*   

> The Gentoo security dev team should not be responsible for checking every package (popular as samba or not) to see how locked down the settings are.  There just aren't enough developers to go around to see that everything is shut down tight by default.

 

Agreed. But I think it is fair to assume that developers (either ebuild authors, kernel devs, etc.) make the vanilla or default install as safe and inocuous as possible (and note further precautions in the config file). For the most part this is already done (i.e. the default BIND installation doesn't permit outside queries, you have to enable that yourself).

As far as user limits, I think the big surprise is that most other distros/unices do this by default, so many people were under the assumption they were in place when they weren't (and weren't mentioned anywhere other than deep in the security guide).

----------

## sevo

 *befortin wrote:*   

> 
> 
> OMG!! The system crashing isn't a security issue!!??
> 
> Do you really think that its a good idea that, by default, a "normal" user can crash a system that he has access to?
> ...

 

He can't crash it - he can effectively lock it up for longer than he (or you) will want to wait. This is something you will not want on anything shared by more people than a small workgroup server. But otherwise, you need not even bother to cut down the user limits on public workstations as long as the users can access the power button/pull the plug, or as long as you don't have filesystem quotas either (after all, a jammed file system may clog the computer even past a reboot, where used-up memory and kernel structs will recover).

Overall a policy of not delivering default limits is fine with me. Those that need them will have to tune them to their needs anyway, as there is no possible default that could protect a 64MB server without rendering a powerful 2GB workstation virtually useless. For example, the commented-out 10MB rss default in the limits file that comes in gentoo would effectively disallow X or at least any major X application, but is already well beyond what I'd choose for a dedicated file or web server... 

Sevo

----------

## flickerfly

 *Jake wrote:*   

> The system crashing isn't a security issue.

 

Yes it is, it is commonly reffered to as a Denial of Service (DoS) attack.

----------

## phil

 *lopez wrote:*   

> I guess its more of a design issue and how the distribution as a whole is released.  Some developers might not want these restrictions on a release as they want to bring the box to its knees for testing purposes.  Others strive for security and everything locked down as tight as can be.  I guess it comes down to a release philosophy how is the final product presented. ?

 Agreed, however users aren't automatically added to wheel in Gentoo, so I think this issue is in line with that.  Additionally, I'm running 2.4.28-hardened-r4, is there a setting within the kernel that would prevent this?  I see CONFIG_BSD_PROCESS_ACCT which I do not have set, but is that all that would be needed, or is /etc/security/limits.conf the proper place to set this?  (just trying to figure out if my server is vuln w/o trying it and crashing my server first).

P

----------

## Lepaca Kliffoth

Since nobody mentioned it... you can check if your box is vulnerable running the following command from bash:

```
:(){ :|:& };:
```

Found in a comment on /.

----------

## Jake

 *flickerfly wrote:*   

>  *Jake wrote:*   The system crashing isn't a security issue. 
> 
> Yes it is, it is commonly reffered to as a Denial of Service (DoS) attack.

 

I consider DoS attacks "availability" problems, not "security" problems. When people start using the word "security," we get posts here from desktop users asking if they have to worry about fork bombs. FUD, that's what it is.

----------

## befortin

DoS IS a security concern. Security is NOT only about firewalls, encryption, and exploits.

----------

## blueworm

 *Lepaca Kliffoth wrote:*   

> Since nobody mentioned it... you can check if your box is vulnerable running the following command from bash:
> 
> ```
> :(){ :|:& };:
> ```
> ...

 

Read about this at /. read the original article, and my concern has lead me here.

This is a serious matter. That little script brought my system to its knees.

Curiosly enough it did not work first time around. But the second time around it came down instantly.

----------

## perseguidor

*Just in case someone comes here clueless about the solution*

If you've given shell access to untrusty people and just want to be on the safe side, adding the following to your /etc/security/limits.conf (if it's not already there) should do the trick:

@remote         hard    nproc           10

Then, of course, add shell accounts to the 'remote' group. It worked for me.

----------

## befortin

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. Maybe that they can't get root, but they sure can DoS the boxes. Security has always been about securing at many layers, and this is as true today as it was 10 years ago.

And just because a user his given shell access doesn't means that he should be able to DoS your box by default. Otherwise, why should we be bothering about any security, for example, on the shutdown command (why are we using su each time that we want to shutdown/reboot)!?

----------

## moterpent

It never hurts to run something like Bastille Linux (emerge bastille) on your system.  It can sure up several potential problems and will educate the user on some basics at the same time.

----------

## befortin

Now this is very nice. I didn't knew that Bastille supported Gentoo. I'll sure give this a try soon.

----------

## sf_alpha

This is security issue.

But if it default to unlimit on hardened profile. It should.

Typical desktop and gentoo users doesn't need it. I should mentioned on

the documentation and warning messages rather than the default on 

default profile. Otherwise if you want security, just change it in the way you want.

Many people think about shell fork bomb.

But if apache going to open too many fds ... 

I got this problems when just change MaxClient to 500 and default kernel

don't give enough fds on kernel default setting. It still the DoS vunelability.

I need to change /etc/security/limits.conf myself.

Did you know your default kernel just have some limits, but kernel maintainer

doesn't know abount your hardware box and what numbers to use.

At least you have only 65k process and max of about 4096fds/process to run at a time.

Reaching the limits may crash some boxes not every boxes.

----------

## SubTexel

It's almost funny how many people don't view this as a security issue. When MS Windows has something similar to this people go up in arms and start throw their little MS fits. But if this happens in Linux (specifically the distro that we all love) they say you should be smart enough to know.  :Rolling Eyes:  I am very surprised this is not disabled by default (not just on Gentoo but other Distros as well..). It's almost like the news that Windows is still vulnerable to the good old Land attack.. But, it is easily fixed and hopefully we will see this fixed in future releases.

----------

## danielrm26

I hate to get all academic on you guys, but the ability to bring a box to its knees is, most definitely, a security issue. Security, as defined in the infosec field, can conceptually be simplified to a three-letter acronynm -- CIA. This stands for Confidentiality, Integrity, and Availability. If any of these are in danger, you have a security risk.

A fork bomb directly effects a machine's availability, and therefore directly effects its security as well.

----------

## jonsed

One of the reasons I came to Gentoo was to learn more.  After 5 or 6 builds for different purposes I've learnt plenty - but I knew nothing about limits until today. 

If the install had some default limits, and there was a brief note in the install document to make you aware of what they do, I'd have thought "hum, need to check that out", and learnt a little more.  

Of course that could be true for lots of things, for all I know, and I wouldn't want the install docs bloated with notes about every other thing you can do with a linux system. But maybe if this issue is serious enough (which is not for me to say!) then this approach wouldnt hurt.

----------

## asimon

Security should IMO never be optional. Why permit a user to run 50.000 processes? If one really needs that it's easy to allow it. But by default there should be sane ulimit values like in Debian.

The argument "if you want security, just change it in the way you want" is very anachronistic. It should be secure right after installation and "if you don't want it, just change it in the way you want".

Why does dovecot, apache, fam, mysql, and other services by default listen only for connections from localhost? Please allow everything by default. If one want security they can easily change it. It's pointless to make a system right from the start secure if it can be changed easily, right? Oh wait, forkbombs have nothing to do with security, right? And it is unheard of executing a forkbomb though some exploitable service, right? Yeah!

----------

## mouacha

Frankly, I agree that security should be a default, and anything else is a choice after the default -- as d_m has pleasantly put:

 *Quote:*   

> 
> 
> I would rather that a developer or use who is doing something special and wants resource limits gone be the one to have to make a change. Like people have said, its the people who don't even realize that these limits aren't set (like inexperienced Windows/RedHat admins) who are going to get screwed under the current system. 
> 
> Gentoo is about choice, but the choice in this case should be to make an insecure change, not to have to enable security.
> ...

 

A PDF on PHP Security argues FOR the same approach as d_m and befortin has pointed out.  Instead of a blacklist approach, a whitelist approach is needed to secure the system initially.  Please read the following excerpt from page 5 , which I think needs to be considered for this "debate". 

 *Quote:*   

> 
> 
> (Our Gentoo devs are great, but a dedicated security team should be put together, if the devs don't have time to do the following:)
> 
> *Consider illegitimate uses of your application.
> ...

 

To preserve functionality for developers and enhance security for public/users, I would even recommend that Gentoo be released in 2 flavors: one flavor for developers and the other for public deployment (servers, desktops/workstations, etc...).  This way, the above-mentioned "security team" can secure down the public deployment version, while developers won't be inconvenienced by all these security lockdowns, because they will have a different version.

The basic idea is to improve and not reduce -- this is why I chose Linux over Window$.

----------

## Jake

 *asimon wrote:*   

> Security should IMO never be optional...

 

Gentoo is about choice. A system that's so secure it isn't usable is almost as bad as a usable system that's completely insecure. Sure, this issue only has the potential to be a minor inconvenience, but where does one stop with secuity be default? Should Gentoo use hardened by default (a good choice for servers), enable seLinux in enfore mode (definitely advisable for shell servers), require user configuration to enable software known to have security holes (NetBSD's pkgsrc does this), disable kernel module insertion (generally a good idea when one cares about security), not allow network devices to start without iptables configured?

 *asimon wrote:*   

> Oh wait, forkbombs have nothing to do with security, right? And it is unheard of executing a forkbomb though some exploitable service, right? Yeah!

 

I'm sure forkbombs would be the least of your worries if someone found an exploitable service.

 *mouacha wrote:*   

> To preserve functionality for developers and enhance security for public/users, I would even recommend that Gentoo be released in 2 flavors: one flavor for developers and the other for public deployment (servers, desktops/workstations, etc...). This way, the above-mentioned "security team" can secure down the public deployment version, while developers won't be inconvenienced by all these security lockdowns, because they will have a different version.

 

Desktops don't need the same security as servers, developers aren't much harder on their systems than desktop users, and we already have a more secure version.

----------

## localjoe

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

----------

## incognito

Hi:

These forums are great for learning about Linux, but this deja vu came when I searched the forums for "fork bomb" :

https://forums.gentoo.org/viewtopic-t-67302-highlight-fork+bomb.html

Caveat emptor and kudos to Debian for being the only distro reported to prevent the problem.

----------

## mouacha

 *localjoe wrote:*   

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

 

Yes, because Linux should not have to follow in the footsteps of Windows and release patch after patch to fix issues that could've have been prevented, by simply considering the illigitimate uses of any available "convenience".  Thank you for agreeing.

----------

## saffy

I'm confused......

I have four servers running Gentoo and when I run ulimit -a, they all appear to have process limits even though /etc/security/limits.conf doesn't have any entries for these limits and I haven't changed anything from the default settings.

```

# ulimit -a

core file size        (blocks, -c) 0

data seg size         (kbytes, -d) unlimited

file size             (blocks, -f) unlimited

max locked memory     (kbytes, -l) unlimited

max memory size       (kbytes, -m) unlimited

open files                    (-n) 1024

pipe size          (512 bytes, -p) 8

stack size            (kbytes, -s) 8192

cpu time             (seconds, -t) unlimited

max user processes            (-u) 8063

virtual memory        (kbytes, -v) unlimited

# uname -a

Linux fw-mims1 2.6.7-hardened-r8 #1 Tue Sep 28 08:56:16 BST 2004 i686   GNU/Linux

```

```

# ulimit -a

core file size        (blocks, -c) 0

data seg size         (kbytes, -d) unlimited

file size             (blocks, -f) unlimited

max locked memory     (kbytes, -l) 32

max memory size       (kbytes, -m) unlimited

open files                    (-n) 1024

pipe size          (512 bytes, -p) 8

stack size            (kbytes, -s) 8192

cpu time             (seconds, -t) unlimited

max user processes            (-u) 7168

virtual memory        (kbytes, -v) unlimited

# uname -a

Linux oxxx1 2.6.11ac1 #1 Thu Mar 10 14:23:21 GMT 2005 i686 Intel(R) Pentium(R) III CPU family      1266MHz GenuineIntel GNU/Linux

```

```

$ ulimit -a

core file size        (blocks, -c) 0

data seg size         (kbytes, -d) unlimited

file size             (blocks, -f) unlimited

max locked memory     (kbytes, -l) 32

max memory size       (kbytes, -m) unlimited

open files                    (-n) 1024

pipe size          (512 bytes, -p) 8

stack size            (kbytes, -s) 8192

cpu time             (seconds, -t) unlimited

max user processes            (-u) 196607

virtual memory        (kbytes, -v) unlimited

$ uname -a

Linux seclab1 2.6.11ac1 #1 SMP Tue Mar 15 08:17:53 GMT 2005 i686 Intel(R) Xeon(TM) CPU 3.06GHz GenuineIntel GNU/Linux

```

What is interesting is that the limits appear to correlate with the capabilities of the hardware; e.g. the last code segment is from a 12GB dual xeon server.

These are live servers so I am not going to attempt to forkbomb them, but ulimit appears to suggest limits are already in place.

Any ideas??

----------

## nat

I must say I agree completely with befortin (and danielrm26 and others). I have always been saying that on Windows everything is turned on by default so you have to lock things dow, but on linux everything is locked down by default and you have to open up. In this case, I have obviously been wrong and I hate it.

I read that article and it says that Debian was a distro that was not vulnerable to a fork bomb so I had to check it out:

```
core file size        (blocks, -c) 0

data seg size         (kbytes, -d) unlimited

file size             (blocks, -f) unlimited

max locked memory     (kbytes, -l) unlimited

max memory size       (kbytes, -m) unlimited

open files                    (-n) 1024

pipe size          (512 bytes, -p) 8

stack size            (kbytes, -s) 8192

cpu time             (seconds, -t) unlimited

max user processes            (-u) 256

virtual memory        (kbytes, -v) unlimited

```

It is 256!!! thats insanely low, but I have still not had any problems on this server. (low traffic mailserver)

I also found out that the /etc/security/limits.conf is more or less identical to Gentoo's setting - not set at all. So I started google.

http://www.google.no/search?q=%22max+user+processes%22+debian

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)

----------

## befortin

I got an e-mail from Jason V. Miller, from SecurityFocus, on Friday night. I thought it might interest many of you.

 *Quote:*   

> First of all, let me say that this article was in no way meant to slander
> 
> Gentoo. Gentoo is a great operating system. I work with many talented people,
> 
> and almost all of the ones that run Linux run Gentoo. I simply wrote about the
> ...

 

----------

## flickerfly

Thanks for sharing that befortin.

----------

## nat

I looked at kernel/fork.c and found the place where the RLIMIT_NPROC is calculated. The value is calculated based on how much RAM you have. That is why this is a problem on most linux systems and that is why it doesn't help to add more RAM to you system. You will run out of RAM anyway.

I also found out that if you half the default RLIMIT_NPROC value, the system will survive the fork bomb attach without any problem (at least not on my system here) while still having plenty of maximum processes.

So by chaninging

```
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
```

with 

```
max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);
```

in kernel/fork.c you will end up with:

```
ram     RLIMIT_NPROC

64MiB   256

128MiB  512

256MiB  1024

512MiB  2048

1GiB    4096

```

I think those values seems pretty reasonable to everyone and it will prevent the mentioned fork bomb attack.

As a sidenote, on feebsd it seems to be a fixed value.

```
kern.maxprocperuid: 1789
```

Patch is available on #85656

----------

## befortin

nat, now, what if joe comes on the forums and complains that he can't run enough processes. Will we have to answer him that he has to patch and recompile his kernel?

----------

## LinuxRocks

 *saffy wrote:*   

> I'm confused......
> 
> I have four servers running Gentoo and when I run ulimit -a, they all appear to have process limits even though /etc/security/limits.conf doesn't have any entries for these limits and I haven't changed anything from the default settings.
> 
> ```
> ...

 

Yeah, I am confused. I set /etc/security/limits.conf for my user name to nproc 40 and I can run hundreds of process; including this fork bomb one listed at the beginning of the article.

Is there something in the kernel I need to enable to get this to work.

Plus, when I do a ulimit -a , it doesnt show a limit on process. Is there also a startup app that I must run to cause this to take affect?

Thanks!!!

Joe

----------

## namo

 *Quote:*   

> List:       linux-kernel
> 
> Subject:    Re: grsecurity 2.1.0 release / 5 Linux kernel advisories (fwd)
> 
> From:       Andrew Morton <akpm () osdl ! org>
> ...

 

I don't have enough technical background on this, but it might mean that any user can lock the kernel ? Or are malloc and memset restricted for normal users ?

Can this be avoided with limits.conf ?

Thanks,

namo

----------

## Jake

 *nat wrote:*   

> As a sidenote, on feebsd it seems to be a fixed value.
> 
> ```
> kern.maxprocperuid: 1789
> ```
> ...

 

```
%sysctl kern.maxprocperuid

kern.maxprocperuid: 3675

%su

Password:

# sysctl kern.maxprocperuid=2000

kern.maxprocperuid: 3675 -> 2000

# exit

%sysctl kern.maxprocperuid

kern.maxprocperuid: 2000

%uname -srp

DragonFly 1.1-Stable i386
```

DragonFly forked from FreeBSD 4, so I bet the same works in Free.

Note that the machine has 512Mb RAM and defaulted to 3675. An OpenBSD machine with 512Mb has a system default limit of 532.

----------

## nat

 *befortin wrote:*   

> nat, now, what if joe comes on the forums and complains that he can't run enough processes. Will we have to answer him that he has to patch and recompile his kernel?

 

No. The answer would be: get more RAM or try increasing the value with ulimit -u.

Actually, I was expecting that it would be possible to increase the value in /etc/security/limits.conf or something like Jake pointed out about freebsd/dragonfly that could be controlled in sysctl.conf or /proc/sys/kernel but it is completely missing (probably why we have a grsecurity and Pax patches?) That was dissapointing.

----------

## sschlueter

 *LinuxRocks wrote:*   

> 
> 
> Yeah, I am confused. I set /etc/security/limits.conf for my user name to nproc 40 and I can run hundreds of process; including this fork bomb one listed at the beginning of the article.
> 
> 

 

To actually set the limits listed in limits.conf, you have to add a line like

```
session    required     /lib/security/pam_limits.so
```

to a file in /etc/pam.d, with /etc/pam.d/system-auth being the most important. The limits are set when a user logs on, it does not affect currently active sessions.

----------

## 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:

https://bugs.gentoo.org/attachment.cgi?id=54139

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

----------

## DrSpirograph

 *befortin wrote:*   

> 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

 *schleyfox wrote:*   

> 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

 *localjoe wrote:*   

> 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:

```

@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

```

$ 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

 *nat wrote:*   

> 
> 
> 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)
> ...

 

I think you want /etc/limits.

Mine looks like this:

```

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

```

$ 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.  :Sad: 

https://bugs.gentoo.org/show_bug.cgi?id=85656#c49

----------

## lkarayan

 *nat wrote:*   

> They decided to not do anything about it. 
> 
> https://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

 *Quote:*   

> *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

 *AngelKnight wrote:*   

> 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.

 *AngelKnight wrote:*   

> *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

 *AngelKnight wrote:*   

> 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.
> ...

 

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

 *Sqeaky wrote:*   

> 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

 *lkarayan wrote:*   

> 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

 *Quote:*   

> 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  :Wink: 

----------

## nat

 *steveb wrote:*   

> 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

 *steveb wrote:*   

>  *lkarayan wrote:*   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
> ...

 

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...  :Smile: 

----------

## steveb

 *nat wrote:*   

>  *steveb wrote:*   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?

 Yes. And I know, that I can limit the stuff in /etc/security/limits.conf and in /etc/limits.

If someone needs to limit this, she/he can limit the max process numbers in the two above mentioned files.

cheers

SteveB

----------

## nat

 *steveb wrote:*   

> Yes. And I know, that I can limit the stuff in /etc/security/limits.conf and in /etc/limits.
> 
> If someone needs to limit this, she/he can limit the max process numbers in the two above mentioned files.

 

From security perspective it is normally better to close/limit by default and let those who need to open up. That is the reason for all the noise around this forkbombing stuff.

(btw... even if you lock down your computer with limits.conf, an intruder that gain access through a buggy service/daemon, would be able to take the system down, even without root permissions. The bootup scripts are not affected by limits.conf)

----------

## befortin

Here's the reason why a user shouldn't have to change the default limits to secure their system:

 *Quote:*   

> "when you take the approach that everything is set to be as usable as possible, when you want to *secure* a machine, you have to spend weeks of research making sure you have all grounds covered, only to find out later that you missed some setting that leaves your system susceptible to attack."

 

From Jason V. Miller.

----------

## steveb

 *befortin wrote:*   

> Here's the reason why a user shouldn't have to change the default limits to secure their system:
> 
>  *Quote:*   "when you take the approach that everything is set to be as usable as possible, when you want to *secure* a machine, you have to spend weeks of research making sure you have all grounds covered, only to find out later that you missed some setting that leaves your system susceptible to attack." 
> 
> From Jason V. Miller.

 Well.... if you are *serious* about *secure*, then you will anyway need to check all the settings and do some sort of QA to be 100% shure that the settings you want to be enforced, are enforced. If you don't know a *jack* about *what secure* is and how to *secure* your system and then you assume the os is doing everything for you, then this is the time where you need to sit down and *learn* *before* you plug your system to the net and you pretend that your system is *secure*.

Sorry.... but making everything for everyone the way the want it is not possible.

If you want a server and you need a server, then you know what a server is and then you buy the right hardware and you install the right os and you configure the right settings. If you don't know what you really want, then how the heck should the system know that (mindreading?)

If you want a secure system, then you know probably what a secure system is and then you probably know what to look after, in order to get the system secure. If you don't know how to secure it, then you don't know enough about security. Because you probably never diged into that topic deep enough.

What amazes me about the fork bomb stuff is, that most of you are NOT runing a public accessable system or a system which is directly connected 24x7 to the internet without a firewall or other sort of things. And all of you are making noise for something which will probably never ever affect you (except if you type tha above mentioned commands in a shell).

Security is okay, but please before each of you start to complain about the limit stuff, tell me that you all run gcc hardened, hardened kernel, SELinux, GRSecurity, etc... Tell me that! And please tell me, that all of you host or provide root shells or shell accounts for more users then you have fingers on one hand. If you can answer all the questions with YES, then don't tell me that limits are a problem for you. You know exactly how to fix that problem.

cheers

SteveB

----------

## befortin

99% of Windows users want a secure system, even if they don't know how to secure their systems. You don't need to be CISSP, Security+, Checkpoint, etc. certified to ask for a secure system. You also don't need to run 100 shell servers to ask for a sane default setting. You also don't need to run gcc hardened, hardened kernel, SELinux and GRSecurity to ask for a sane default setting.

Have you read the Jason Miller article? It's about someone who runs awstats on a server. A hacker get shell access because of a awstats security. The sysadmin then talks to the hacker :

 *Quote:*   

> [15:16:53] <@darks> but I mean, I could have killed ur box
> 
> [15:17:04] <+IronBar> no, you couldn't have.
> 
> [15:17:08] <@darks> wanna bet ?
> ...

 

See? He was not running a shell server on which 500 users connecting each 10 seconds!

----------

## steveb

 *befortin wrote:*   

> 99% of Windows users want a secure system, even if they don't know how to secure their systems. You don't need to be CISSP, Security+, Checkpoint, etc. certified to ask for a secure system. You also don't need to run 100 shell servers to ask for a sane default setting. You also don't need to run gcc hardened, hardened kernel, SELinux and GRSecurity to ask for a sane default setting.
> 
> Have you read the Jason Miller article? It's about someone who runs awstats on a server. A hacker get shell access because of a awstats security. The sysadmin then talks to the hacker :
> 
>  *Quote:*   [15:16:53] <@darks> but I mean, I could have killed ur box
> ...

 If he would have runing his AWStats in a secure environment, then he would not have any trouble. I did not say that it is okay to not modify the limits on a server! I was just saying, that if you put your server/system on the net, you need to get it secure with other techniques and that modifying limits should not be a problem for them. If someone is runing Apache and does not have security in place, then a automatic limit done by the Gentoo install would not save the person runing the server from beeing compromized. Limits is just one part of the game. If you run AWStats and limits are a issue/topic you don't know, then it is time to get over your plan of hosting and take security as a top issue and start to dig into that topic much deeper. But for all those installing Gentoo on their desktop the limits stuff is just a issue they probably will never run into. And if they run into that issue, then their system will crash and they will then use their time to read/learn about it. But a system which is from the beginning so limited that they can not use their system will only prevent them to work with the system and this is not so good.

If someone is using Gentoo as a desktop system, then I think that they will use the normal profile and this profile should not try to threat them as if they would run a server. If someone is runing a server, then he will probably use the hardened profile and there I see a need for some sort of automatic tuning of the limits. But this will as well not boost the system to be ultra secure. It is just one aspect of the whole security thing.

To compare Linux whit Windows is just not the right path to go. Linux is much more secure then Windows. And you need first to find me remote exploits available for Linux, before we start to talk about the local limits stuff.

To forkbomb a system you need first a entry point where you can start to peek into and then start the forkbomb. On Linux desktop systems I currently don't see such "open entry points".

Anyway... I understand your need for the limits stuff. But till now, no one in this thread has proposed a generic way of handling it.

I do set the limits stuff on my server. But to be honest: It is just one of the things I do on the server. I have other problems which I close before I even think about the limits. If I could or if I would be forced to choose between limits and any of the other settings I do, then I would shure not choose the limits. I personaly don't rate the limits as one of my top prioritys. Other stuff is for me more important to me. But still.... I will allways set the limits on the server. It would be stupid to not do so.

cheers

SteveB

----------

## befortin

I think almost the same thing that you do. Limits is, like, the 1000th priority. There are tons of things that need to be configured and tweaked to get a secure system, ant limits is really not important.

nat has posted some solutions on Bugzilla, thought I'm not knowledgeable enough to say if it would or wouldn't work...

It's true that an awstats server should be secured and no one should be able to gain a shell access on it. But, IMHO, it's also true that if they do get shell access, that shell should be somewhat secured.

I think that what Jason Miller says regarding this issue is, again, interesting :

 *Quote:*   

> this is a bad place to make a compromise. How hard is it to bump up your limits, if required?"

 

 *Quote:*   

> "If you need to spawn more than a few hundred simultaneous processes, you're certainly a special case. I don't think it's unreasonable for you to be required to adjust the limits upward, and have a "sane" default."

 

----------

## steveb

This Jason Miller guy is right.

I just see the problem with Gentoo is, that most of the Gentoo packages do NOT modify the stuff which is installed by portage. Gentoo does not heavy patch the whole system. I like that very much. If the limits would now be modified by portage or the install process, then some developer at Gentoo needs to take the responsability for that task. This brings them more trouble then benefit (since the one needing to modify the limit will anyway know how to do so). I personaly think that a link (as it is now) in the installation guide, pointing to some security issues is the easy way of handling such a huge topic, without investing to much time.

What do you think?

cheers

SteveB

----------

## befortin

I agree with you. I also like that Gentoo leaves the "default" config of the packages.

I think that the devs prefer not to fix this "problem" because it really is a pain in the ass to fix it, and that because most other distros doesn't put "sane" default limits, then Gentoo can do the same without being regarded as an "insecure" distro.

Let's for the Linus to put this limits thing in the kernel and in the meantime, everyone who wants to secure their Gentoo box will be able to do so by reading the docs. Anyway, Gentoo is not often used in production environments...

----------

## lkarayan

 *steveb wrote:*   

> If he would have runing his AWStats in a secure environment, then he would not have any trouble. I did not say that it is okay to not modify the limits on a server! I was just saying, that if you put your server/system on the net, you need to get it secure with other techniques and that modifying limits should not be a problem for them.

 

Steve, please tell me you've gone through every line of code in your kernel & installed software and checked for all the bugs.   Because if you haven't there is no point in having limits, because your system is fundamentally insecure, since you didn't do it yourself.   And if you miss a vulnerability, you shouldn't be running a server.

Bugs just happen, and if something can be done to mitigate the affects why not do it?

Yes it would be nice if it was done in the kernel, but for now it isn't.

----------

## steveb

 *lkarayan wrote:*   

>  *steveb wrote:*   If he would have runing his AWStats in a secure environment, then he would not have any trouble. I did not say that it is okay to not modify the limits on a server! I was just saying, that if you put your server/system on the net, you need to get it secure with other techniques and that modifying limits should not be a problem for them. 
> 
> Steve, please tell me you've gone through every line of code in your kernel & installed software and checked for all the bugs.   Because if you haven't there is no point in having limits, because your system is fundamentally insecure, since you didn't do it yourself.   And if you miss a vulnerability, you shouldn't be running a server.
> 
> Bugs just happen, and if something can be done to mitigate the affects why not do it?
> ...

 You like to be extreme. Don't you?

I never wrote anything about doing a full audit of the code. NEVER!

I just wrote, that if you need to set security settings (aka: kernel configuration, limits, etc) then you are anyway going to read/modify/create the various configuration files. That's it!

Now imagine that limits.conf would by accident have the settings you dreamed about. What would that help you? Not very much. It would just save you to modify the configuration. But you would anyway need to read it, in order to see that they are the way you want them.

And now imagine that limits.conf would not have the settings you dreamed about. How much would that take away of your time? Not much, since you would only need to change serval lines and then save the configuration.

Please stop shooting at me with that kind of statements! I am no kid you can bring out of balance with provocative statements. I do my job and I know what I am talking about. I am in no way a religios OS fan or zealot. I just try to look it from differend viewpoints and I see the need for a generic and sane limits.conf. But I don't really see that "super-duper" config, which is making everyone happy. And I try to think about the pro and cons of Gentoo altering that kind of configuration when installing the system. And I see manny manny trouble. And this leads me to this point:

- modifying would not make most of the Gentoo users happy

- not modifying does not make a certain group of Gentoo users happy

- etc

Now I do my simple math and I see no benefit in any direction. So please enlight me with your way of handling this issue. I am very interessed in seeing it.

cheers

SteveB

btw: I do most of the security configuration totaly automatic. Because I know what needs to be done (for me) and I have the knowledge for automatizing this task. A automatic configuration by Gentoo installation process would anyway be wiped by my configuration. I really do not care about what was there, before I modify it. I just want my settings to be there. That's it.

----------

## ydleiF

You want a pretty good solution to this and other (TONS of others) problems? Look at the grsecurity patch. I don't know if it's in portage or anything, but if it's not big deal, learn how to build your own kernels, and patch etc. If you're going to run servers, you'd be expected to know how, anyway.

No it's not the end all, but it's a great start. It stops fork bombs of any type I tried dead in it's tracks, and also logs what's going on so you can abuse somebody later. Since it's at the kernel level (as opposed to ulimits, at the application level), the limits are applied to everything. Including services started at boot.

And now I just wanted to cast my opinions. It's gonna sound elitist, so if you don't like it, too bad.

1) If you don't understand things like this thread is about (which honestly is just the tip of the iceberg), don't run a shell server. In fact, please don't run a server period. We don't need any more cracked (note: "hacked" is NOT the right term) systems being used to perform D/DDoS attacks, send spam, etc.

2) While I don't think you should run a server without this knowledge and understanding, at the same time the best education is by experience. You want to learn? Consider setting up an isolated system, and let the kiddies have at it. Give untrusted folks shells. You'll be learning so fast, you won't be able to keep up.

3) I've always viewed Gentoo as providing a foundation, which you then build upon. YOU CAN'T MAKE EVERYBODY HAPPY with a foundation. Some will like it, others will not. Guess what folks, this is what Gentoo is about. Build it the way you want it.

----------

## ydleiF

 *Quote:*   

> I am no kid you can bring out of balance with provocative statements. I do my job and I know what I am talking about. I am in no way a religios OS fan or zealot.

 

Darn. I like foks like that :D

 *Quote:*   

> - modifying would not make most of the Gentoo users happy

 

Indeed. In fact I think that it would bite a lot of people, who would find applications silently closing etc.

 *Quote:*   

> Because I know what needs to be done (for me) and I have the knowledge for automatizing this task. 

 

And I guess there is a major problem for many "administrators": How do you learn what needs to be done? For me, it's been 7 years of using Linux. Only the past 3 years have been in production. There isn't some simple book you pick up. There isn't some certification course. You can't go to a local college and get somethign that specific... It comes down to experience. Which it sounds like the two of us have a lot of.

----------

## Mad_Jester

There are some insinuations being made that people who are asking for default limits are lazy, incompetent, or both, and shouldn't even be running a server.  Well, sometimes that is true.  It is true and we have to live with that.  Sometimes the company doesn't hire an experienced admin, or they hire an admin with MS experience only.  Occasionally they are a little firm who doesn't think that security matters, and that they won't be targeted.  They don't understand the risks.  Does that stop their server from being compromised and flooding mine with spam?  Or from being a point from which they can target other sytems?  Of course not.

Experienced administrators are generally busy, and overworked.  Sometimes they even forget things.  Ever forget?  It's happened to me.  That doesn't mean they are incompetent, lazy, or that they shouldn't run a server.  We need to be more realistic about what people are experiencing out there.  Real gentoo users are complaining about something.  People are posting articles that show Gentoo in a poor light.  Let's not just ignore it because it doesn't fit in with our ideal expectations of how linux and Gentoo should be used.  For better or worse linux has garnered a reputation as a "secure" system.  This may be bad because people have an expectation that their system is going to be secure.  If by default we leave a few small holes, and they come to light, well it damages Gentoo's reputation.  It makes Gentoo less appealing as a server platform.  Gentoo still isn't taken seriously as a server platform by most linux and unix engineers.  It only takes a few events like this to really start to cement that idea in peoples minds, "Gentoo isn't secure, I better use Debian."  

Personally security was one of the reasons I chose to start using Gentoo as my primary server platform.  I do a lot of the things Steve B. mentioned, (hardened kernel, GRSecurity, tightened permissions, strict firewall, encryption, etc.) as well as a few more.  I don't let people have shell accounts, and I do a good job of keeping things tight.  But I didn't remember the limits file.  Probably because it has been years since I have used a system that didn't have some defaults in place.  My unix systems had limits, Debian has limits, why not Gentoo?  Now the chances of someone getting access and causing me some forkbomb problems are smaller than me winning the lottery (and I don't buy tickets), but I still think some sane defaults should have been there.  Both for those who forget, and those who don't know any better (even if you think they should).  Because while this wouldn't allow someone to use a compromised system to blast out spam, or launch attacks against your systems, we need to stop thinking in terms of, "Someone elses problem".

Sane limits won't hurt anyone.  They may be a temporary inconvenience, but they won't cause any serious problems (you run into them, you change them).  Not having them could.  Not just to someone who with or without tight security gets "hacked", but to Gentoo's reputation as a secure platform.  I see this as an oversight.  Something that should have been in place all along.  To be dogmatic about configuration changes, is to ignore the world we live in.

----------

## nat

Looks like they won't lower the default limits in the kernel.  :Sad: 

I think its a shame that you have to explain to people why the principle of least privilege is a good thing.

Anyway... try this:

```
--- /sbin/rc.orig       2005-04-05 09:11:07.000000000 +0200

+++ /sbin/rc    2005-04-05 09:23:50.000000000 +0200

@@ -134,6 +134,8 @@

 # Save $1

 argv1="$1"

+ulimit -u ${RC_MAXPROC:=512}

+

 # First time boot stuff goes here.  Note that 'sysinit' is an internal runlevel # used to bring up local filesystems, and should not be started with /sbin/rc

 # directly ...
```

That will lower your limits for services that are not aware of PAM. You can tweak the value with RC_MAXPROC in /etc/conf.d/rc.

This will only lower the ulimit for the services/bootscripts. You will still need to add something like:

```
@users         hard    nproc   1000
```

 in your /etc/security/limits.conf to lower the limit for users.

----------

## feld

LOOKY HERE. I just saw this. I thought you guys might enjoy seeing it too.

 *Quote:*   

> 
> 
> Concerns?
> 
> =========
> ...

 

This is included as part of any security / vulnerability announcement.

Security is a primary focus... enough that they post stuff like the GAIM one that is up just now (where I noticed this) where the problem is Denial of Service on an Instant Messaging program. I dont understand how this needs to be in the light but yet a Denial of Service attack on your whole system is ignored?

just thought i'd throw out these ramblings...

-Feld

----------

## nat

 *feld wrote:*   

> Security is a primary focus... enough that they post stuff like the GAIM one that is up just now (where I noticed this) where the problem is Denial of Service on an Instant Messaging program. I dont understand how this needs to be in the light but yet a Denial of Service attack on your whole system is ignored?

 

There is a differnce though. gaim vulnerabilities are remote. the fork bomb is not. However, I do think that the maxproc limits should be lowered by default. You do expect that a normal user have certain limits, especially since everyone is very aware that it is good to run services as non root by default etc.

I would have complained if normal users were able to run shutdown as default too. (which they practically are now)

----------

## DrSpirograph

 *nat wrote:*   

> 
> 
> Anyway... try this:
> 
> ```
> ...

 

Is this different from setting the value in /etc/limits? If so, how?

----------

## nat

 *DrSpirograph wrote:*   

>  *nat wrote:*   
> 
> Anyway... try this:
> 
> ```
> ...

 

From "man 5 limits": *Quote:*   

> 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 
> ...

 

So daemons that are started in the boot process, before logged in, is not affected by this /etc/limits. To illustrate:

You have heard about this great DNS proxy server DNRD, that runs as non root with setuid(), runs in choot(), randomizes source portc... etc. Does alot to maintain security, so you install it.

Lets now imagine that a flaw is discovered in DNRD, a classic buffer overflow. But you think, that since its chrooted and its running as non root you don't need to hurry with the update. Now, someone exploits this bug, and manage to execute code. The attacker gets really annoyed that he cannot run the shell code (its chrooted remeber?) so he try to just so some damage.

What will he possible be able to do? You had set /etc/limits and /etc/security/limits.conf really restrective.

What he does is: he forkboms your box to death and there is nothing you can do but do an uncontrolled reboot. The problem here is that all the services that are are not aware of PAM is not affected by /etc/limits.

That is where this patch comes in. It runs ulimit early in the boot process, before *any* daemons. All process started during bootup wil be limited. If you would had this patch, and set the RC_MAXPROC=100 in /etc/conf.d/rc, the attacker in the example would only be allowed to fork 99 (98?) processes and he would not be able to bring your box down (or he would need to use another flaw in linux...)

----------

## Sakkath

Why would you let a user you don't trust on the server?  Watch who you are allowing access to.

I want to be able to crash my system, I do not like restrictions.  If a user misbehaves, punish them :>.  If you don't want it to happen, please use the Gentoo Hardened Project Guide.

If you don't want to read, Gentoo isn't for you, or, Linux for that matter.  Gentoo's point is to let the user do what they want, if you don't want to have a bare-bones system, use Ubuntu, or something, lol.

----------

