когда приходит пакет с отресом отправителя совпадающим с адресом получателя, и винда от этого дуреет . По слухам, lang атака опять работает в Windows после установки SP2 :)))
Фигня все это. Если ulimit позволяет более-менее нормально работать - то злоумышленник все равно может вызвать resource exhaustion, просто чуть менее тривиальными методами. Типа "запускаем process limit программ, каждая из которых выделяет максимально доступное количество памяти, и начинает в цикле записывать по байту в каждую страницу". Еще можно файлов понасоздавать и писать в случайные места. И т.д.
Статья - идиотизм. Думаю, любые *nix будут падать, если лимиты не проставлять. Под *bsd они проставляются на основе login-классов, под linux надо проставлять руками.
Бред и ерунда :) работает как всегда :) даже лучше чем в hp-ux 11.11 автор гонит :) во первых впросто все уперается в r_limit и этим порожденным процесам форк в цикле возвращает -1 тоесть.. они даже ресурсов почти е выжирают :) пожно зайти под другим пользователем и кильнуть их все :)
а вообще можно проще $cat > f1 f1 & f1 & ^D $chmod u+x f1 $f1
Гы.. а может имеется ввиду, что в этих дистрибутивах .. без дополнительных настроек.. .. при установки из коробки.. не определены соответсвующие лимиты для пользователей?
Статью надо было всё-таки почитать. Автор упирает на то, что 1) В шапке, мандрейке и проч. дистрах (кстати, кроме дебиана - там всё ок) по умолчанию не выставлены "разумные" лимиты на локальных пользователей 2) что это всё должно контролирооваться ядром по умолчанию.
Сходил, прочитал. Потом попробовал. Ничего не падает, если установлены лимиты на пользовательские процессы. А они, разумеется, установлены... Думаю, откровенная лажа, или пробовали на дистре из коробки, который установлен с настройками по дефолту. Прежде всего, отрывать лапы админу, и пинать по голове до до полного просветления!
Ребята, а вы на голову не долбанулись? Нафига ЯДРУ контролировать это, да еще "по-умолчанию"?!
Нормальная система ограничений - все что нужно. Ядро - оно должно ресурсы предоставлять, а не зажимать. Может, кому-то для вполне штатных действий понадобится породить 1000 потомков (апачу каком-нибудь), а ядро скаже - фигушки! у меня лимит на 100. Может еще и перекомпиляцию потребуете, новаторы, блин...
Прошу прощения, деиствительно как-то пропустил... Но это не даёт право на безграмотное администрирование систем! После установки система должна быть настроена конкретно для каждого пользователя (IMHO).
Вообще то RLIMIT_NPROC устанавливается в ядре!!! конечно и обычный пользователь его увеличить не может!
fork.c:129: init_task.signal->rlim[RLIMIT_NPROC].rlim_cur = max_threads/2;
fork.c:130: init_task.signal->rlim[RLIMIT_NPROC].rlim_max = max_threads/2;
fork.c:121: max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
fork.c:126: if(max_threads < 20)
fork.c:127: max_threads = 20;
так вот :) дома у меня RLIMIT_NPROC (по умолчанию) 4095
на работе 3839
так что
А в чем, собственно, проблема? Ежели шелл не давать никому (типичный десктоп) , то на кой эти лимиты по умолчанию. Ну повесит чайник десктоп, да и барабан ему на шею. Редко на каком серваке шелл простому смертному открыт. Ну а там где это делают, дураков уже перестреляли.
спокойно порушит. даже если ограничение в улимите на процессы и выделяемую память.
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
int main(void){
while (fork()){
}
while (1){
malloc(1024);
}
return 0;
}
>>slackware 10.0 не упал :) - покряхтел минуты две и ожил (без ребута :)))
и чего сказал когда ожил?
вообще програмка страшная :)
покажи что там у тебя в ulimit -a
>>в который раз луникс отссосал у бзди, а все потому, что не учатся на своих ошибках :)
>>все-таки не подходят луниксы для серверов - desktop only.
форкбомба она и в бзди форкбомба.. да и в винде тоже
А я думал, что это как в C - "вы берете и простреливаете себе ногу".Т.е. если ты не выставил сам разумные ограничения, то будешь сам себе злобный буратина.