No forkbomb protection by default !?!

[steveb]

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]

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:

"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]

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

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

[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 ?
[15:17:27] <@darks> forkbomb it

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

[steveb]

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 :

[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 ?
[15:17:27] <@darks> forkbomb it

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

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 :

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

"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]

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]

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.

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]

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

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

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.

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:

Code: Select all

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

Code: Select all

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

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
security@gentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

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]

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]

Anyway... try this:

Code: Select all

--- /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}
+
...

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

[nat]

Anyway... try this:

Code: Select all

--- /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}
+
...

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

From "man 5 limits":

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.