"[SauronDeMordor]" wrote in message <dm7igo$857j$:
vu ce que tu dit j espere que tu a monte /tmp et noexec
Quelle drôle d'idée. /tmp, c'est très bien pour compiler des trucs.
[SauronDeMordor]
"[SauronDeMordor]" wrote in message <dm7igo$857j$:
vu ce que tu dit j espere que tu a monte /tmp et noexec
Quelle drôle d'idée. /tmp, c'est très bien pour compiler des truc s. oui surtout si c est pas ta machine et que tu a utilisé une vulnérabi lité pour y aller.
cf une vulnerabilité de openssl/apache qui permétait d executer du co de arbitraire a partir de /tmp et qui etait suid.
tous les serveurs qui etaient en nosuid pas touchés (ou peut) et ceux e n no exec, rien du tout.
et pour compiler /tmp n est pas l idéal, pas fait pour cela.
"[SauronDeMordor]" wrote in message <dm7igo$857j$1@ng1.exabot.com>:
vu ce que tu dit j espere que tu a monte /tmp et noexec
Quelle drôle d'idée. /tmp, c'est très bien pour compiler des truc s.
oui surtout si c est pas ta machine et que tu a utilisé une vulnérabi lité pour y aller.
cf une vulnerabilité de openssl/apache qui permétait d executer du co de arbitraire a partir de /tmp et qui etait suid.
tous les serveurs qui etaient en nosuid pas touchés (ou peut) et ceux e n no exec, rien du tout.
et pour compiler /tmp n est pas l idéal, pas fait pour cela.
"[SauronDeMordor]" wrote in message <dm7igo$857j$:
vu ce que tu dit j espere que tu a monte /tmp et noexec
Quelle drôle d'idée. /tmp, c'est très bien pour compiler des truc s. oui surtout si c est pas ta machine et que tu a utilisé une vulnérabi lité pour y aller.
cf une vulnerabilité de openssl/apache qui permétait d executer du co de arbitraire a partir de /tmp et qui etait suid.
tous les serveurs qui etaient en nosuid pas touchés (ou peut) et ceux e n no exec, rien du tout.
et pour compiler /tmp n est pas l idéal, pas fait pour cela.
Nicolas George
"[SauronDeMordor]" wrote in message <dmentj$88k6$:
cf une vulnerabilité de openssl/apache qui permétait d executer du code arbitraire a partir de /tmp et qui etait suid.
Eh bien, quand on a un serveur vulnérable, on l'upgrade.
et pour compiler /tmp n est pas l idéal, pas fait pour cela.
Je persiste, c'est très bien, en particulier la possibilité de faire tout le boulot sans toucher aux disques.
PS : tu fais des lignes trop longues.
"[SauronDeMordor]" wrote in message <dmentj$88k6$1@ng1.exabot.com>:
cf une vulnerabilité de openssl/apache qui permétait d executer du code
arbitraire a partir de /tmp et qui etait suid.
Eh bien, quand on a un serveur vulnérable, on l'upgrade.
et pour compiler /tmp n est pas l idéal, pas fait pour cela.
Je persiste, c'est très bien, en particulier la possibilité de faire tout le
boulot sans toucher aux disques.
"[SauronDeMordor]" wrote in message <dmentj$88k6$:
cf une vulnerabilité de openssl/apache qui permétait d executer du code arbitraire a partir de /tmp et qui etait suid.
Eh bien, quand on a un serveur vulnérable, on l'upgrade.
et pour compiler /tmp n est pas l idéal, pas fait pour cela.
Je persiste, c'est très bien, en particulier la possibilité de faire tout le boulot sans toucher aux disques.
PS : tu fais des lignes trop longues.
[SauronDeMordor]
"[SauronDeMordor]" wrote in message <dmentj$88k6$:
cf une vulnerabilité de openssl/apache qui permétait d executer du code arbitraire a partir de /tmp et qui etait suid.
Eh bien, quand on a un serveur vulnérable, on l'upgrade.
quand le patch est pas encore la, ou la vulnerailite pas dectectee tu te fais avoir dans les grandes largeures.
de plus l upgrade n est pas forcement la reponse a un probleme de secu, c ar il peut y avoir des contraindication ou des contraintes de producation sur u n serveur qui empeche les upgrade.
une machine corectyement utilisee et installee et CONFIGUREE est toujours plus sure qu une machine installee en Gruik, meme si cette derniere est a jour et pas l autre
et pour compiler /tmp n est pas l idéal, pas fait pour cela.
Je persiste, c'est très bien, en particulier la possibilité de fair e tout le boulot sans toucher aux disques.
tss, /tmp est un disque meme si tu le met en ram par tmpfs, tu n as qu a faire un autre /Compile a la place.
PS : tu fais des lignes trop longues.
sorry, il y a quelques mois j avais fait une modif pour la taille des lig nes et oublier de remetre a 80 collones(voila qui est fait)
"[SauronDeMordor]" wrote in message <dmentj$88k6$1@ng1.exabot.com>:
cf une vulnerabilité de openssl/apache qui permétait d executer du code
arbitraire a partir de /tmp et qui etait suid.
Eh bien, quand on a un serveur vulnérable, on l'upgrade.
quand le patch est pas encore la, ou la vulnerailite pas dectectee tu te fais
avoir dans les grandes largeures.
de plus l upgrade n est pas forcement la reponse a un probleme de secu, c ar il
peut y avoir des contraindication ou des contraintes de producation sur u n
serveur qui empeche les upgrade.
une machine corectyement utilisee et installee et CONFIGUREE est toujours plus
sure qu une machine installee en Gruik, meme si cette derniere est a jour et pas
l autre
et pour compiler /tmp n est pas l idéal, pas fait pour cela.
Je persiste, c'est très bien, en particulier la possibilité de fair e tout le
boulot sans toucher aux disques.
tss, /tmp est un disque meme si tu le met en ram par tmpfs, tu n as qu a faire
un autre /Compile a la place.
PS : tu fais des lignes trop longues.
sorry, il y a quelques mois j avais fait une modif pour la taille des lig nes et
oublier de remetre a 80 collones(voila qui est fait)
"[SauronDeMordor]" wrote in message <dmentj$88k6$:
cf une vulnerabilité de openssl/apache qui permétait d executer du code arbitraire a partir de /tmp et qui etait suid.
Eh bien, quand on a un serveur vulnérable, on l'upgrade.
quand le patch est pas encore la, ou la vulnerailite pas dectectee tu te fais avoir dans les grandes largeures.
de plus l upgrade n est pas forcement la reponse a un probleme de secu, c ar il peut y avoir des contraindication ou des contraintes de producation sur u n serveur qui empeche les upgrade.
une machine corectyement utilisee et installee et CONFIGUREE est toujours plus sure qu une machine installee en Gruik, meme si cette derniere est a jour et pas l autre
et pour compiler /tmp n est pas l idéal, pas fait pour cela.
Je persiste, c'est très bien, en particulier la possibilité de fair e tout le boulot sans toucher aux disques.
tss, /tmp est un disque meme si tu le met en ram par tmpfs, tu n as qu a faire un autre /Compile a la place.
PS : tu fais des lignes trop longues.
sorry, il y a quelques mois j avais fait une modif pour la taille des lig nes et oublier de remetre a 80 collones(voila qui est fait)
Nicolas George
"[SauronDeMordor]" wrote in message <dmfbrd$88pg$:
de plus l upgrade n est pas forcement la reponse a un probleme de secu, car il peut y avoir des contraindication ou des contraintes de producation sur un serveur qui empeche les upgrade.
Peut-être, quoi qu'il en soit, quand il y a un trou, il faut le boucher. Les rustines du style noexec dans /tmp ne sont pas quelque chose de fiable.
tss, /tmp est un disque meme si tu le met en ram par tmpfs, tu n as qu a faire un autre /Compile a la place.
Je ne vois pas l'intérêt de disperser les resources.
sorry, il y a quelques mois j avais fait une modif pour la taille des lignes et oublier de remetre a 80 collones(voila qui est fait)
Il faut régler à moins, 76 ou 72, pour permettre les citations.
"[SauronDeMordor]" wrote in message <dmfbrd$88pg$1@ng1.exabot.com>:
de plus l upgrade n est pas forcement la reponse a un probleme de secu,
car il peut y avoir des contraindication ou des contraintes de producation
sur un serveur qui empeche les upgrade.
Peut-être, quoi qu'il en soit, quand il y a un trou, il faut le boucher. Les
rustines du style noexec dans /tmp ne sont pas quelque chose de fiable.
tss, /tmp est un disque meme si tu le met en ram par tmpfs, tu n as qu a
faire un autre /Compile a la place.
Je ne vois pas l'intérêt de disperser les resources.
sorry, il y a quelques mois j avais fait une modif pour la taille des
lignes et oublier de remetre a 80 collones(voila qui est fait)
Il faut régler à moins, 76 ou 72, pour permettre les citations.
"[SauronDeMordor]" wrote in message <dmfbrd$88pg$:
de plus l upgrade n est pas forcement la reponse a un probleme de secu, car il peut y avoir des contraindication ou des contraintes de producation sur un serveur qui empeche les upgrade.
Peut-être, quoi qu'il en soit, quand il y a un trou, il faut le boucher. Les rustines du style noexec dans /tmp ne sont pas quelque chose de fiable.
tss, /tmp est un disque meme si tu le met en ram par tmpfs, tu n as qu a faire un autre /Compile a la place.
Je ne vois pas l'intérêt de disperser les resources.
sorry, il y a quelques mois j avais fait une modif pour la taille des lignes et oublier de remetre a 80 collones(voila qui est fait)
Il faut régler à moins, 76 ou 72, pour permettre les citations.
[SauronDeMordor]
"[SauronDeMordor]" wrote in message <dmfbrd$88pg$:
de plus l upgrade n est pas forcement la reponse a un probleme de secu, car il peut y avoir des contraindication ou des contraintes de producat ion sur un serveur qui empeche les upgrade.
Peut-être, quoi qu'il en soit, quand il y a un trou, il faut le bouch er. Les rustines du style noexec dans /tmp ne sont pas quelque chose de fiable.
quand il y a un trou et que le trou _ET_ que tu es sensible a celui ci. c ar si
pas impacte alors pas d upgrade, on upgrade pas pour le plaisir. car cela peut introduire de nouveaux bug qui peuvent poser probleme
noexec n ets pas une rustine, mais bel et bien une recommendation
tss, /tmp est un disque meme si tu le met en ram par tmpfs, tu n as qu a faire un autre /Compile a la place.
Je ne vois pas l'intérêt de disperser les resources.
sorry, il y a quelques mois j avais fait une modif pour la taille des lignes et oublier de remetre a 80 collones(voila qui est fait)
Il faut régler à moins, 76 ou 72, pour permettre les citations.
"[SauronDeMordor]" wrote in message <dmfbrd$88pg$1@ng1.exabot.com>:
de plus l upgrade n est pas forcement la reponse a un probleme de secu,
car il peut y avoir des contraindication ou des contraintes de producat ion
sur un serveur qui empeche les upgrade.
Peut-être, quoi qu'il en soit, quand il y a un trou, il faut le bouch er. Les
rustines du style noexec dans /tmp ne sont pas quelque chose de fiable.
quand il y a un trou et que le trou _ET_ que tu es sensible a celui ci. c ar si
pas impacte alors pas d upgrade, on upgrade pas pour le plaisir. car cela peut
introduire de nouveaux bug qui peuvent poser probleme
noexec n ets pas une rustine, mais bel et bien une recommendation
tss, /tmp est un disque meme si tu le met en ram par tmpfs, tu n as qu a
faire un autre /Compile a la place.
Je ne vois pas l'intérêt de disperser les resources.
sorry, il y a quelques mois j avais fait une modif pour la taille des
lignes et oublier de remetre a 80 collones(voila qui est fait)
Il faut régler à moins, 76 ou 72, pour permettre les citations.
"[SauronDeMordor]" wrote in message <dmfbrd$88pg$:
de plus l upgrade n est pas forcement la reponse a un probleme de secu, car il peut y avoir des contraindication ou des contraintes de producat ion sur un serveur qui empeche les upgrade.
Peut-être, quoi qu'il en soit, quand il y a un trou, il faut le bouch er. Les rustines du style noexec dans /tmp ne sont pas quelque chose de fiable.
quand il y a un trou et que le trou _ET_ que tu es sensible a celui ci. c ar si
pas impacte alors pas d upgrade, on upgrade pas pour le plaisir. car cela peut introduire de nouveaux bug qui peuvent poser probleme
noexec n ets pas une rustine, mais bel et bien une recommendation
tss, /tmp est un disque meme si tu le met en ram par tmpfs, tu n as qu a faire un autre /Compile a la place.
Je ne vois pas l'intérêt de disperser les resources.
sorry, il y a quelques mois j avais fait une modif pour la taille des lignes et oublier de remetre a 80 collones(voila qui est fait)
Il faut régler à moins, 76 ou 72, pour permettre les citations.
Nicolas George
"[SauronDeMordor]" wrote in message <dmfhm6$88qu$:
quand il y a un trou et que le trou _ET_ que tu es sensible a celui ci. car si pas impacte alors pas d upgrade, on upgrade pas pour le plaisir. car cela peut introduire de nouveaux bug qui peuvent poser probleme
Évidemment.
noexec n ets pas une rustine, mais bel et bien une recommendation
noexec sur /tmp, sur une machine généraliste et pas un serveur spécialisé, c'est pénible, c'est tout. Si on veut isoler tel ou tel serveur, il y a chroot ou les namespaces qui servent à ça.
"[SauronDeMordor]" wrote in message <dmfhm6$88qu$1@ng1.exabot.com>:
quand il y a un trou et que le trou _ET_ que tu es sensible a celui ci.
car si pas impacte alors pas d upgrade, on upgrade pas pour le plaisir.
car cela peut introduire de nouveaux bug qui peuvent poser probleme
Évidemment.
noexec n ets pas une rustine, mais bel et bien une recommendation
noexec sur /tmp, sur une machine généraliste et pas un serveur spécialisé,
c'est pénible, c'est tout. Si on veut isoler tel ou tel serveur, il y a
chroot ou les namespaces qui servent à ça.
"[SauronDeMordor]" wrote in message <dmfhm6$88qu$:
quand il y a un trou et que le trou _ET_ que tu es sensible a celui ci. car si pas impacte alors pas d upgrade, on upgrade pas pour le plaisir. car cela peut introduire de nouveaux bug qui peuvent poser probleme
Évidemment.
noexec n ets pas une rustine, mais bel et bien une recommendation
noexec sur /tmp, sur une machine généraliste et pas un serveur spécialisé, c'est pénible, c'est tout. Si on veut isoler tel ou tel serveur, il y a chroot ou les namespaces qui servent à ça.
[SauronDeMordor]
"[SauronDeMordor]" wrote in message <dmfhm6$88qu$:
quand il y a un trou et que le trou _ET_ que tu es sensible a celui ci. car si pas impacte alors pas d upgrade, on upgrade pas pour le plaisir. car cela peut introduire de nouveaux bug qui peuvent poser probleme
Évidemment.
noexec n ets pas une rustine, mais bel et bien une recommendation
noexec sur /tmp, sur une machine généraliste et pas un serveur spé cialisé, c'est pénible, c'est tout. Si on veut isoler tel ou tel serveur, il y a chroot ou les namespaces qui servent à ça.
un chroot, il me faudrait 20 seconde pour m en echaper, je pense pas que ca soit
une securite. ca serais plus dur sur le file system ebergeant le chroot e tait en nodev aussi. quand aux namespaces??? tu veux parler des jail, ou des environement sous pax ou grsecurity?
si tu veux avoir une config machine si complex qu elle devient ingerable alors qu une solution simple suffit, grand bien t en fasse.
"[SauronDeMordor]" wrote in message <dmfhm6$88qu$1@ng1.exabot.com>:
quand il y a un trou et que le trou _ET_ que tu es sensible a celui ci.
car si pas impacte alors pas d upgrade, on upgrade pas pour le plaisir.
car cela peut introduire de nouveaux bug qui peuvent poser probleme
Évidemment.
noexec n ets pas une rustine, mais bel et bien une recommendation
noexec sur /tmp, sur une machine généraliste et pas un serveur spé cialisé,
c'est pénible, c'est tout. Si on veut isoler tel ou tel serveur, il y a
chroot ou les namespaces qui servent à ça.
un chroot, il me faudrait 20 seconde pour m en echaper, je pense pas que ca soit
une securite. ca serais plus dur sur le file system ebergeant le chroot e tait en
nodev aussi.
quand aux namespaces??? tu veux parler des jail, ou des environement sous pax ou
grsecurity?
si tu veux avoir une config machine si complex qu elle devient ingerable alors
qu une solution simple suffit, grand bien t en fasse.
"[SauronDeMordor]" wrote in message <dmfhm6$88qu$:
quand il y a un trou et que le trou _ET_ que tu es sensible a celui ci. car si pas impacte alors pas d upgrade, on upgrade pas pour le plaisir. car cela peut introduire de nouveaux bug qui peuvent poser probleme
Évidemment.
noexec n ets pas une rustine, mais bel et bien une recommendation
noexec sur /tmp, sur une machine généraliste et pas un serveur spé cialisé, c'est pénible, c'est tout. Si on veut isoler tel ou tel serveur, il y a chroot ou les namespaces qui servent à ça.
un chroot, il me faudrait 20 seconde pour m en echaper, je pense pas que ca soit
une securite. ca serais plus dur sur le file system ebergeant le chroot e tait en nodev aussi. quand aux namespaces??? tu veux parler des jail, ou des environement sous pax ou grsecurity?
si tu veux avoir une config machine si complex qu elle devient ingerable alors qu une solution simple suffit, grand bien t en fasse.
Nicolas George
"[SauronDeMordor]" wrote in message <dmhj4p$89q8$:
un chroot, il me faudrait 20 seconde pour m en echaper,
Seulement si tu as déjà les droits de root.
ca serais plus dur sur le file system ebergeant le chroot etait en nodev aussi.
Utiliser un chroot permet de mettre les attributs que tu veux aux filesystems utilisés par le serveur sans faire chier les autres utilisateurs de la machine.
quand aux namespaces??? tu veux parler des jail, ou des environement sous pax ou grsecurity?
Non, je voulais parler de l'option CLONE_NEWNS de clone.
"[SauronDeMordor]" wrote in message <dmhj4p$89q8$1@ng1.exabot.com>:
un chroot, il me faudrait 20 seconde pour m en echaper,
Seulement si tu as déjà les droits de root.
ca serais plus dur sur le file system ebergeant le chroot
etait en nodev aussi.
Utiliser un chroot permet de mettre les attributs que tu veux aux
filesystems utilisés par le serveur sans faire chier les autres utilisateurs
de la machine.
quand aux namespaces??? tu veux parler des jail, ou des environement sous
pax ou grsecurity?
Non, je voulais parler de l'option CLONE_NEWNS de clone.
"[SauronDeMordor]" wrote in message <dmhj4p$89q8$:
un chroot, il me faudrait 20 seconde pour m en echaper,
Seulement si tu as déjà les droits de root.
ca serais plus dur sur le file system ebergeant le chroot etait en nodev aussi.
Utiliser un chroot permet de mettre les attributs que tu veux aux filesystems utilisés par le serveur sans faire chier les autres utilisateurs de la machine.
quand aux namespaces??? tu veux parler des jail, ou des environement sous pax ou grsecurity?
Non, je voulais parler de l'option CLONE_NEWNS de clone.
