Coucou les systèmes vérolés, ici les systèmes sains :)
Les systèmes anciens n'ont rien de moins vérolé que les système s actuels. Tous les mktemp(), les gets(), les strcat(), c'est sur les systèmes a nciens qu'on les trouve.
Compromis ou pas mon utilisateur n'a pas d'accès en écriture sur / usr tant qu'il ne connait pas le mot de passe _root_, ne peut pas non plus executer une commande critique sans ce même mot de passe.
On s'en fout que ce soit le mot de passe « _root_ » ou « *root* » ou encore « !!!!!root!!!!! » ou bien se faire scanner la rétine. Ce qui com pte, c'est que l'identité de l'utilisateur soit vérifiée plus soigneusement lors de l'exécution d'une commande critique.
Lui fournir des mécanismes lui permettant d'outrepasser des commande s (sudo + ~./local/*.desktop) qui ne s'y situent pas par hasard dans /usr/bin, /bin ou /sbin, sous prétexte de XXIème siècle c'est co nfondre progrès et nouveauté, vitesse et précipitation, utilité et fac ilité.
Tu n'as manifestement rien compris à la problématique dont il est q uestion dans ce thread.
Ces histoires de sudo / ~/.local/*.desktop, alias et compagnie, c'est d u flan, c'est des semi-débutants qui montrent qu'ils connaissent une fe ature et demie de plus que leur voisin.
Le fait de base est que si tu donnes ton mot de passe d'élévation d e privilèges à un compte compromis, tu compromets les privilèges é levés. Que ce soit fait en changeant le PATH, en faisant un lanceur local, en bidouillant le shell ou en ptraçant l'ensemble de la session, c'est j uste un détail d'implémentation. Un exploit sérieux utilisera toutes ces méthodes en combinaison de toutes façons.
connerie et c'est quoi la granularité entre usr standard et sudo dans la plupart des cas et quand t'es sudo tu ne peut pas compromettre les autre cte ?
l'os on sen fous se sont mes donner perso les plus précieuse
remy
-- http://remyaumeunier.chez-alice.fr/
Le 23/12/2014 19:18, Nicolas George a écrit :
Doug713705 , dans le message <6uhombx24r.ln2@actarus.redatomik.org>, a
écrit :
Coucou les systèmes vérolés, ici les systèmes sains :)
Les systèmes anciens n'ont rien de moins vérolé que les système s actuels.
Tous les mktemp(), les gets(), les strcat(), c'est sur les systèmes a nciens
qu'on les trouve.
Compromis ou pas mon utilisateur n'a pas d'accès en écriture sur / usr
tant qu'il ne connait pas le mot de passe _root_, ne peut pas non plus
executer une commande critique sans ce même mot de passe.
On s'en fout que ce soit le mot de passe « _root_ » ou « *root* » ou encore
« !!!!!root!!!!! » ou bien se faire scanner la rétine. Ce qui com pte, c'est
que l'identité de l'utilisateur soit vérifiée plus soigneusement lors de
l'exécution d'une commande critique.
Lui fournir des mécanismes lui permettant d'outrepasser des commande s
(sudo + ~./local/*.desktop) qui ne s'y situent pas par hasard dans
/usr/bin, /bin ou /sbin, sous prétexte de XXIème siècle c'est co nfondre
progrès et nouveauté, vitesse et précipitation, utilité et fac ilité.
Tu n'as manifestement rien compris à la problématique dont il est q uestion
dans ce thread.
Ces histoires de sudo / ~/.local/*.desktop, alias et compagnie, c'est d u
flan, c'est des semi-débutants qui montrent qu'ils connaissent une fe ature
et demie de plus que leur voisin.
Le fait de base est que si tu donnes ton mot de passe d'élévation d e
privilèges à un compte compromis, tu compromets les privilèges é levés. Que
ce soit fait en changeant le PATH, en faisant un lanceur local, en
bidouillant le shell ou en ptraçant l'ensemble de la session, c'est j uste un
détail d'implémentation. Un exploit sérieux utilisera toutes ces méthodes en
combinaison de toutes façons.
connerie et c'est quoi la granularité entre usr standard et sudo
dans la plupart des cas et quand t'es sudo tu ne peut pas compromettre
les autre cte ?
l'os on sen fous se sont mes donner perso les plus précieuse
Coucou les systèmes vérolés, ici les systèmes sains :)
Les systèmes anciens n'ont rien de moins vérolé que les système s actuels. Tous les mktemp(), les gets(), les strcat(), c'est sur les systèmes a nciens qu'on les trouve.
Compromis ou pas mon utilisateur n'a pas d'accès en écriture sur / usr tant qu'il ne connait pas le mot de passe _root_, ne peut pas non plus executer une commande critique sans ce même mot de passe.
On s'en fout que ce soit le mot de passe « _root_ » ou « *root* » ou encore « !!!!!root!!!!! » ou bien se faire scanner la rétine. Ce qui com pte, c'est que l'identité de l'utilisateur soit vérifiée plus soigneusement lors de l'exécution d'une commande critique.
Lui fournir des mécanismes lui permettant d'outrepasser des commande s (sudo + ~./local/*.desktop) qui ne s'y situent pas par hasard dans /usr/bin, /bin ou /sbin, sous prétexte de XXIème siècle c'est co nfondre progrès et nouveauté, vitesse et précipitation, utilité et fac ilité.
Tu n'as manifestement rien compris à la problématique dont il est q uestion dans ce thread.
Ces histoires de sudo / ~/.local/*.desktop, alias et compagnie, c'est d u flan, c'est des semi-débutants qui montrent qu'ils connaissent une fe ature et demie de plus que leur voisin.
Le fait de base est que si tu donnes ton mot de passe d'élévation d e privilèges à un compte compromis, tu compromets les privilèges é levés. Que ce soit fait en changeant le PATH, en faisant un lanceur local, en bidouillant le shell ou en ptraçant l'ensemble de la session, c'est j uste un détail d'implémentation. Un exploit sérieux utilisera toutes ces méthodes en combinaison de toutes façons.
connerie et c'est quoi la granularité entre usr standard et sudo dans la plupart des cas et quand t'es sudo tu ne peut pas compromettre les autre cte ?
l'os on sen fous se sont mes donner perso les plus précieuse
remy
-- http://remyaumeunier.chez-alice.fr/
Bruno Ducrot
On 2015-01-30, Doug713705 wrote:
Le 30-01-2015, tth nous expliquait dans fr.comp.os.linux.debats (<magf43$n3j$) :
On 01/30/2015 06:05 PM, Geoffray « fatalerrors » Levasseur a dit:
Pour résumer, le moyen age sur et efficace est préférable à la modernité stupide et arrogante (ou dans le dénie ou mal conçue, au choix).
Doug713705 wrote:
Le 23-12-2014, Nicolas George nous expliquait dans fr.comp.os.linux.configuration (<549986aa$0$2490$) :
Au moyen-age, le goretquotage n'avait pas encore été inventé.
Il sera introduit par erreur en 1284 par Marty McFly couchant sur parchemin une réponse au professeur Emmett Brown.
Mais pour le voir il faudra attendre 2032, date annoncée du prochain orage capable de fournir 21 GigoWatts en un seul éclair.
On peut aussi utiliser IPOT : http://perso.duckcorp.org/duck/mirrors/kadreg.free.fr/ipot/
A plus,
-- Bruno Ducrot
A quoi ca sert que Ducrot hisse des carcasses ?
On 2015-01-30, Doug713705 wrote:
Le 30-01-2015, tth nous expliquait dans
fr.comp.os.linux.debats
(<magf43$n3j$1@uind.cispeo.fr>) :
On 01/30/2015 06:05 PM, Geoffray « fatalerrors » Levasseur a dit:
Pour résumer, le moyen age sur et efficace est préférable à la modernité
stupide et arrogante (ou dans le dénie ou mal conçue, au choix).
Doug713705 wrote:
Le 23-12-2014, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<549986aa$0$2490$426a74cc@news.free.fr>) :
Au moyen-age, le goretquotage n'avait pas encore été inventé.
Il sera introduit par erreur en 1284 par Marty McFly couchant sur
parchemin une réponse au professeur Emmett Brown.
Mais pour le voir il faudra attendre 2032, date annoncée du prochain
orage capable de fournir 21 GigoWatts en un seul éclair.
On peut aussi utiliser IPOT :
http://perso.duckcorp.org/duck/mirrors/kadreg.free.fr/ipot/
