Andrew Benton wrote: > Hello, > > I've wrote to LFS support before about fork bombs. Last July I learned > how to prevent them by limiting the number of processes a user can have > with /etc/limits. Recently I've been working on installing linux-PAM > (for ssh, it gives me more options to use PAM. I want to open ssh to > the internet so I'm hardening things up a bit). > > As part of my testing I tried a fork bomb and was horrified to discover > that nothing I did with PAM could prevent the fork bomb from locking up > the system. Then I tried it on a system that didn't have PAM (it still > had just shadow) and the result was the same, the fork bomb made the > system unresponsive. I can't remember what version of shadow I was > using last July but I can't make shadow-4.1.4.3 limit the number of > processes and protect against a fork bomb. > > I've just rebuilt a system with shadow-4.0.18.1 and when I run a fork > bomb the shell fills up with "Resource temporarily unavailable" (ie, > shadow-4.0.18.1 has done it's job and limited the number of processes), > the system stays responsive, I can log out and shut down cleanly. > Basically, shadow-4.0.18.1 works. The current version (shadow-4.1.4.3) > is broken. With or without PAM it cannot limit the number of processes. > It seems to me that any system with shadow-4.1.4.3 is vulnerable to a > fork bomb. We should go back to 4.0.18.1, which works.
bash has a built in ulimit command, PAM has a pam_limits module, and shadow uses /etc/limits. I don't think any of these actually control the limits, but sets a value for the kernel to do it. I suspect you have a kernel issue, not a pam or shadow issue. Checking some more, shadow is doing setrlimit() system calls. See the man page. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
