Bombe fork et ulimit

Emmanuel CHANTREAU <echant@brouillard.aima.fr> écrit:

Rien n'empêche un utilisateur ayant un compte shell de faire planter une
machine unix. Par ce script:

#!/bin/bash
while true; do
$0 &
done

C'est un peut fort quand même pour un OS se voulant sécurisé.
Existe-t-il un moyen d'empêcher ça avec Linux ?

En mettant des limites.

Si vous pensez à "ulimit -u" (the maximum number of user processes)
ça ne limite que sur les processus enfants directes, si vous ne me croyez
pas essayez ;->

ça veut dire qu'il y aurait un bug dans linux (le noyau)
ou bash (ulimit) ?

Si je lis bien la description disponible sur "man bash", je lis ceci :

-u The maximum number of processes available to a single
user.

Cela me semblerait bizarre.

--
DINH V. Hoa,

"ben le problème c'est que les voitures à motorisations XXL
ça passe rarement inaperçu" -- raoul

Emmanuel CHANTREAU a écrit:

Existe-t-il un moyen d'empêcher ça avec Linux ?

Les infos les plus fraiches sur le sujet me semblent être :

http://testing.lkml.org/slashdot.php?mid22469

Peut-être obtiendras-tu plus d'infos sur un groupe plus spécialisé.

--
Antoine Bellot

DINH Viêt Hoà écrit:

Si vous pensez à "ulimit -u" (the maximum number of user processes)
ça ne limite que sur les processus enfants directes, si vous ne me croyez
pas essayez ;->

ça veut dire qu'il y aurait un bug dans linux (le noyau)
ou bash (ulimit) ?

Si je lis bien la description disponible sur "man bash", je lis ceci :

-u The maximum number of processes available to a single
user.

Cela me semblerait bizarre.

Et pourtant... voici un script moins destructeur qui le prouve:
(il faut être root pour modifier les limites):

P=$(ps axu|grep ^root|wc -l);
ulimit -S -u $((P+1))
ulimit -H -u $((P+1))
export n=0;
export s='if [ $n -lt 10 ]; then
n=$((n+1));
ps axu|grep ^root|wc -l;
ulimit -S -u
ulimit -H -u
bash -c "$s";
else
echo "fin"
sleep 10s
fi';
eval "$s"

Ce script met les limites au nombre de processus de root+1 puis lance 10
bash imbriqués, plus que permis.

cordialement


--
Emmanuel Chantréau
100% des gens sont dans une minorité de moins de 5% des gens.

"Emmanuel CHANTREAU" <echant@brouillard.aima.fr> a écrit dans le message de
news:3f576c10$0$1115$626a54ce@news.free.fr...
| Laurent Wacrenier écrit:
| > Emmanuel CHANTREAU <echant@brouillard.aima.fr> écrit:
| >> Rien n'empêche un utilisateur ayant un compte shell de faire planter
une
| >> machine unix. Par ce script:
| >>
| >> #!/bin/bash
| >> while true; do
| >> $0 &
| >> done
| >>
| >> C'est un peut fort quand même pour un OS se voulant sécurisé.
| >> Existe-t-il un moyen d'empêcher ça avec Linux ?
| >
| > En mettant des limites.

etant dans un thread unix et le post initial parlant d UNIX et pas de linux
on a suivant les systemes des fichier comme


/etc/sysconfigtab pour Digital Unix/tru64Unix
/etc/system pour sun

surement des truc equivalent pour les autres systemes

et linux n est pas en reste il y a aussi (outre patch grsecurity)
/etc/security/limits.conf


donc la bombe fork sur un system corectement configure (genre apres la
premiere bombe du genre) n aura plus d effet catastrophique, juste du lag

|
| Si vous pensez à "ulimit -u" (the maximum number of user processes)
| ça ne limite que sur les processus enfants directes, si vous ne me croyez
| pas essayez ;->
|
| --
| Emmanuel Chantréau
| 100% des gens sont dans une minorité de moins de 5% des gens.

Emmanuel CHANTREAU <echant@brouillard.aima.fr> wrote:

(il faut être root pour modifier les limites):

[root@gump src]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm)
,6(disk),10(wheel)
[root@gump src]# ulimit -u 100
[root@gump src]# ulimit -u 1000
[root@gump src]# ulimit -u 10000
[root@gump src]# su - lemen
[lemen@gump lemen]$ id
uidp1(lemen) gid0(users)
[lemen@gump lemen]$ ulimit -u 1000
[lemen@gump lemen]$ ulimit -u 10000
bash: ulimit: cannot modify limit: Operation not permitted
[lemen@gump lemen]$ ulimit -u 10
[lemen@gump lemen]$ ulimit -u 100
bash: ulimit: cannot modify limit: Operation not permitted
[lemen@gump lemen]$ ulimit -u 1
[lemen@gump lemen]$ w
bash: fork: Resource temporarily unavailable


Votre script qui tourne en root, c'est normal qu'il depasse la limit.
C'est le seul compte sur lequel il ne faut pas l'utiliser.

ulimit a mettre dans /etc/profile et s'assurer que tous les shells
dispo sur le system rendent visite a /etc/profile a login/su, sinon un
coup de chsh et le ulimit saute.

Dans d'autre system, on dispose d'une limite global au kernel, mais
difficile de distinguer les users. Sous linux, je ne connais pas cette
voie

Stephane Le Men <ianti-psma-slemen@wanadoo.fr> écrit:

ulimit a mettre dans /etc/profile et s'assurer que tous les shells
dispo sur le system rendent visite a /etc/profile a login/su, sinon un
coup de chsh et le ulimit saute.

Bof, il suffit alors de lancer le truc dans la crontab.

Le Fri, 5 Sep 2003 14:30:51 +0200, [SauroN]
<titi@toto.com.invalid> ecrivait:

Bonjour,

donc la bombe fork sur un system corectement configure (genre apres la
premiere bombe du genre)....

ou apres la lecture de ce thread :-))

--

Laurent Wacrenier <lwa> wrote:

Stephane Le Men <ianti-psma-slemen@wanadoo.fr> écrit:

ulimit a mettre dans /etc/profile et s'assurer que tous les shells
dispo sur le system rendent visite a /etc/profile a login/su, sinon un
coup de chsh et le ulimit saute.

Bof, il suffit alors de lancer le truc dans la crontab.

Saligo ! et tu m'aurais fait le coup sur at et les r*command et les cgi
aussi j'imagine ? En general, je croise mes contraintes sur les services
que je laisse ouvert. Ceci dit, sur cron/at/rsh, je n'ai rien d'autre a
proposer que l'adaption/recompile du shell sous linux.
Une autre soluce plus simple ?

Stephane Le Men <ianti-pams-slemen@wanadoo.fr> écrit:

Saligo ! et tu m'aurais fait le coup sur at et les r*command et les cgi
aussi j'imagine ? En general, je croise mes contraintes sur les services

Sur xdm aussi.

que je laisse ouvert. Ceci dit, sur cron/at/rsh, je n'ai rien d'autre a
proposer que l'adaption/recompile du shell sous linux.
Une autre soluce plus simple ?

Sur FreeBSD, les limites sont centralisées (dans /etc/login.conf) et
tous les démons sont sensés les initialiser en changeant d'uid.