No forkbomb protection by default !?!

Message

befortin · Post by **befortin** » Thu Mar 17, 2005 2:39 pm

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

Here's an interesting 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 · Post by **lopez** » Thu Mar 17, 2005 3:40 pm

Check out Section #6 User/group limitations

Code: Select all

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

Code: Select all

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 · Post by **befortin** » Thu Mar 17, 2005 3:47 pm

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

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

lopez · Post by **lopez** » Thu Mar 17, 2005 4:14 pm

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 · Post by **Jake** » Thu Mar 17, 2005 4:27 pm

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 · Post by **befortin** » Thu Mar 17, 2005 4:29 pm

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 :

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

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

befortin · Post by **befortin** » Thu Mar 17, 2005 4:36 pm

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?

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 · Post by **mark_lagace** » Thu Mar 17, 2005 4:48 pm

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

Jake · Post by **Jake** » Thu Mar 17, 2005 5:08 pm

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 · Post by **befortin** » Thu Mar 17, 2005 6:00 pm

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.

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.

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 · Post by **d_m** » Thu Mar 17, 2005 6:40 pm

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 · Post by **befortin** » Thu Mar 17, 2005 7:06 pm

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.

59729 · Post by **59729** » Thu Mar 17, 2005 7:46 pm

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

digital_ · Post by **digital_** » Thu Mar 17, 2005 8:14 pm

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 · Post by **befortin** » Thu Mar 17, 2005 9:04 pm

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 · Post by **beandog** » Thu Mar 17, 2005 9:27 pm

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 · Post by **d_m** » Thu Mar 17, 2005 9:33 pm

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

d_m · Post by **d_m** » Thu Mar 17, 2005 9:38 pm

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 · Post by **sevo** » Fri Mar 18, 2005 1:31 am

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 · Post by **flickerfly** » Fri Mar 18, 2005 5:27 pm

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 · Post by **phil** » Fri Mar 18, 2005 5:46 pm

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 · Post by **Lepaca Kliffoth** » Fri Mar 18, 2005 7:12 pm

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

Code: Select all

:(){ :|:& };:

Found in a comment on /.

Jake · Post by **Jake** » Fri Mar 18, 2005 7:24 pm

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 · Post by **befortin** » Fri Mar 18, 2005 7:27 pm

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

blueworm · Post by **blueworm** » Fri Mar 18, 2005 8:10 pm

Lepaca Kliffoth wrote:Since nobody mentioned it... you can check if your box is vulnerable running the following command from bash:
Code: Select all
:(){ :|:& };:
Found in a comment on /.

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.