You are not logged in.
Does anybody know what are default/sugested/common limits on *BSD systems? They would probably be a good reference.
good idea
Offline
I did some checking on my other boxes:
On debian sarge there are no limits set, /etc/security/* are all commented out. I wonder why that article said debian was fork-bomb proof. Maybe they tested woody.
On FreeBSD 5.3 there is no /etc/security/ at all. There must be limits set even without pam, because I can fork "only" about 3628 processes and then I get "resource temporarily unavailable". Funny, even with more than 3700 processes (of all users) running, the system is still very stable and responsive.
Offline
Ok, zero questions of me answered. Also I already said that the max depends on your hardware. I give up...
Offline
Ok, zero questions of me answered. Also I already said that the max depends on your hardware. I give up...
As for "sane limits" being default for Arch, I think the first step is to choose a "standard" system. Like say, 1Ghz w. 256MB ram. People who have a slower computer can always set it lower, and people with a faster computer will be well protected by the default.
What would you guys consider a reasonable default system? Again, my bid is 1Ghz 256MB
fffft!
Offline
To summarize:
My p3 600 Mhz + 256 Mb ram can recover when the limit is 2048 processes per user. To be on the safe side taking the halve of that, 1024, seems reasonable.
mico mysteriously has problems with the 1024 limit, while his "default" limit is somehow lower. That are two riddles in one.
Now the remaining question is if 1024 isn't already insanely high, and if using a higher default limit actually adds anything. I think not, but if anyone disagrees then say so.
Offline
My laptop crashes even with these rules when I use the bash varaint:
@users hard nproc 256
@users soft nproc 128
What does this mean? Should I lower them?
edit: It looks like /etc/security/limits.conf is completely being ignored here.
ulimit -u returns 3831, while I have set it to 256.
edit2: I think it has to do with kdm. limit.conf is only being processed on an ordinary console login.
Offline
is 'users' the only group the user you are testing with is a member of?
ie. is the user being tested a member of other groups, like wheel?
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
I replaced @users (which I was part of) with *. Still the same: max 3818 procs in X and 128 in console, according to ulimit -u.
Offline
interesting. Now that I run ulimit -a, I realize that ulimit is not reporting correct values for me either...
*scratches chin*
man limits says the file should be /etc/limits. It makes a reference to LIMITS_FILE variable, being defined somewhere else. Also, limits is, I believe, part of the pam stack. Maybe it is not being called..
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
/etc/limits is only used when PAM is disabled afaik.
I think I've found the cause. When I don't start kdm at boot (or stop it) and run startx, the values are correct. So it has something to do with my login manager.
Offline
Apparently kdm and/or gdm don't have pam support, or it's broken ("ldd `which kdm` | grep pam" should give answer).
Offline
kdm has pam support. I did some research and found out, that 'session required pam_limits.so' line is missing in /etc/pam.d/kde-np. It works just well with that.
*/me toddles to Mr. Bugtracker*
Offline
Hym, I wonder. openssh (sshd) doesn't use pam in default, therefore it doesn't respect limits.conf settings. As, I presume, the biggest danger of forkbomb attack comes from remote users, don't you think sshd config should default to the use of pam (at least account and session, not necessarily auth) and its limit settings? Even if someone sets reasonable limits, overlooking this sshd setting may cause him some troubles. What's your opinion, guys?
Offline
lucke, I think that is indeed why my limits appear to not be observed. If limits don't work via ssh, then what good are they..
Probably just a flag missing in the sshd conf file..
*rustles around in man pages*
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
There's a UsePam sshd config option...
An alternative may be to set the limits before starting sshd, but that's not a nice solution.
Offline
Yep, there's UsePam, but by default it's set to No. And, what I was talking about in my previous post, imho it should be set to Yes by default ('sed' it during the build process, that is).
Offline
thanks guys.
I set
ChallengeResponseAuthentication=no
UsePAM yes
and it is working fine now.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Yep, there's UsePam, but by default it's set to No. And, what I was talking about in my previous post, imho it should be set to Yes by default ('sed' it during the build process, that is).
I'll second that - post a feature request to the bug tracker 8)
Offline
It's still not working with kdm here.
my /etc/pam.d/kde-ng:
#%PAM-1.0
auth required pam_nologin.so
auth required pam_permit.so
account required pam_unix.so service=system-auth
password required pam_unix.so service=system-auth
session required pam_unix.so service=system-auth
session optional pam_console.so
session required pam_limits.so
Offline
It works properly here O_o
Are you sure you have proper limits set in limits.conf and does it actually show different values in virtual console and in Konsole?
Btw, filename is kde-np, not ng ;-)
Offline
Wow. I thought my system would be immune to a forkbomb for some reason. Using the -cko kernel, I killed my system in about 1 second using the bash forkbomb.
Needless to say, /etc/security/limits.conf is now set up properly.
·¬»· i am shadowhand, powered by webfaction
Offline
It works properly here O_o
Are you sure you have proper limits set in limits.conf and does it actually show different values in virtual console and in Konsole?
Btw, filename is kde-np, not ng ;-)
* hard nproc 200
* soft nproc 200
@users hard nproc 80
@users soft nproc 50
@users - maxlogins 4
about kde-np: typo
I am sure that in a virtual console the values differ from within kde.
Offline
Sry for reactivating this topic, but after reading the whole thread im still not sure if arch is per default protected against such fork bombs?! :?
I checked /etc/security/limits.conf but only these one were present
* - rtprio 0
* - nice 0
@audio - rtprio 65
@audio - nice -10
@audio - memlock 40000
cheers,
detto
Offline
It's not. It's easy enough to put in the relevant setting though.
Offline
It's not. It's easy enough to put in the relevant setting though.
Mh ok. Easy enough thats true. But why this isnt realized yet to default, i mean it would make not that much work i guess, but pretend those from fork bombs who dont know before how to protect themselves.
cheers,
detto
Offline