Et sinon, ne pas oublier de n'avoir rien à cacher ou si c'est
malheureusement le cas de cacher cela sur une clef usb cryptée.
Oh? Et d'après toi, n'y aurait il pas moyen de modifier le programme
qui demande le mot de passe de ta clé chiffrée?
Et sinon, ne pas oublier de n'avoir rien à cacher ou si c'est
malheureusement le cas de cacher cela sur une clef usb cryptée.
Oh? Et d'après toi, n'y aurait il pas moyen de modifier le programme
qui demande le mot de passe de ta clé chiffrée?
Et sinon, ne pas oublier de n'avoir rien à cacher ou si c'est
malheureusement le cas de cacher cela sur une clef usb cryptée.
Oh? Et d'après toi, n'y aurait il pas moyen de modifier le programme
qui demande le mot de passe de ta clé chiffrée?
Doug713705 , dans le message , 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èmes actuels.
Tous les mktemp(), les gets(), les strcat(), c'est sur les systèmes anciens
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 compte, 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 commandes
(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 confondre
progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Tu n'as manifestement rien compris à la problématique dont il est question
dans ce thread.
Ces histoires de sudo / ~/.local/*.desktop, alias et compagnie, c'est du
flan, c'est des semi-débutants qui montrent qu'ils connaissent une feature
et demie de plus que leur voisin.
Le fait de base est que si tu donnes ton mot de passe d'élévation de
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 juste un
détail d'implémentation. Un exploit sérieux utilisera toutes ces méthodes en
combinaison de toutes façons.
Donc tout ce que tu gagnes à utiliser des technologies périmées depuis
vingt-cinq ans, c'est qu'un exploit automatisé qui ne prévoit que les
méthodes vieilles de moins de vingt ans se vautrera. Tu reconnaîtras que
c'est assez dérisoire, comme gain.
La contrepartie, c'est que tu perds tous les avantages des technologies
modernes. Pour sudo par rapport à su, on peut citer, en vrac : le logging
des opérations privilégiées, la possibilité de configurer le niveau
d'authentification requis (pouvoir lancer poweroff sans mot de passe, mais
pas vim /etc/shadow), la possibilité d'avoir plusieurs administrateurs sans
qu'ils soient obligés de partager le même mot de passe, éviter de faire les
opérations intermédiaires (genre lire un man) avec les privilèges élevés,
partager l'historique entre les commandes privilégiées et les commandes
normales, ne pas laisser de cartouche chargée trop longtemps si on oublie de
laisser tomber les privilèges, etc.
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èmes actuels.
Tous les mktemp(), les gets(), les strcat(), c'est sur les systèmes anciens
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 compte, 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 commandes
(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 confondre
progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Tu n'as manifestement rien compris à la problématique dont il est question
dans ce thread.
Ces histoires de sudo / ~/.local/*.desktop, alias et compagnie, c'est du
flan, c'est des semi-débutants qui montrent qu'ils connaissent une feature
et demie de plus que leur voisin.
Le fait de base est que si tu donnes ton mot de passe d'élévation de
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 juste un
détail d'implémentation. Un exploit sérieux utilisera toutes ces méthodes en
combinaison de toutes façons.
Donc tout ce que tu gagnes à utiliser des technologies périmées depuis
vingt-cinq ans, c'est qu'un exploit automatisé qui ne prévoit que les
méthodes vieilles de moins de vingt ans se vautrera. Tu reconnaîtras que
c'est assez dérisoire, comme gain.
La contrepartie, c'est que tu perds tous les avantages des technologies
modernes. Pour sudo par rapport à su, on peut citer, en vrac : le logging
des opérations privilégiées, la possibilité de configurer le niveau
d'authentification requis (pouvoir lancer poweroff sans mot de passe, mais
pas vim /etc/shadow), la possibilité d'avoir plusieurs administrateurs sans
qu'ils soient obligés de partager le même mot de passe, éviter de faire les
opérations intermédiaires (genre lire un man) avec les privilèges élevés,
partager l'historique entre les commandes privilégiées et les commandes
normales, ne pas laisser de cartouche chargée trop longtemps si on oublie de
laisser tomber les privilèges, etc.
Doug713705 , dans le message , 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èmes actuels.
Tous les mktemp(), les gets(), les strcat(), c'est sur les systèmes anciens
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 compte, 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 commandes
(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 confondre
progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Tu n'as manifestement rien compris à la problématique dont il est question
dans ce thread.
Ces histoires de sudo / ~/.local/*.desktop, alias et compagnie, c'est du
flan, c'est des semi-débutants qui montrent qu'ils connaissent une feature
et demie de plus que leur voisin.
Le fait de base est que si tu donnes ton mot de passe d'élévation de
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 juste un
détail d'implémentation. Un exploit sérieux utilisera toutes ces méthodes en
combinaison de toutes façons.
Donc tout ce que tu gagnes à utiliser des technologies périmées depuis
vingt-cinq ans, c'est qu'un exploit automatisé qui ne prévoit que les
méthodes vieilles de moins de vingt ans se vautrera. Tu reconnaîtras que
c'est assez dérisoire, comme gain.
La contrepartie, c'est que tu perds tous les avantages des technologies
modernes. Pour sudo par rapport à su, on peut citer, en vrac : le logging
des opérations privilégiées, la possibilité de configurer le niveau
d'authentification requis (pouvoir lancer poweroff sans mot de passe, mais
pas vim /etc/shadow), la possibilité d'avoir plusieurs administrateurs sans
qu'ils soient obligés de partager le même mot de passe, éviter de faire les
opérations intermédiaires (genre lire un man) avec les privilèges élevés,
partager l'historique entre les commandes privilégiées et les commandes
normales, ne pas laisser de cartouche chargée trop longtemps si on oublie de
laisser tomber les privilèges, etc.
Justement en quoi sudo répond à cette problématique ?
Tout ce qui peut être fait avec une bonne gestion de groupes en fait.
Justement en quoi sudo répond à cette problématique ?
Tout ce qui peut être fait avec une bonne gestion de groupes en fait.
Justement en quoi sudo répond à cette problématique ?
Tout ce qui peut être fait avec une bonne gestion de groupes en fait.
Donc tout ce que tu gagnes à utiliser des technologies périmées depuis
vingt-cinq ans, c'est qu'un exploit automatisé qui ne prévoit que les
méthodes vieilles de moins de vingt ans se vautrera. Tu reconnaîtras que
c'est assez dérisoire, comme gain.
Donc tout ce que tu gagnes à utiliser des technologies périmées depuis
vingt-cinq ans, c'est qu'un exploit automatisé qui ne prévoit que les
méthodes vieilles de moins de vingt ans se vautrera. Tu reconnaîtras que
c'est assez dérisoire, comme gain.
Donc tout ce que tu gagnes à utiliser des technologies périmées depuis
vingt-cinq ans, c'est qu'un exploit automatisé qui ne prévoit que les
méthodes vieilles de moins de vingt ans se vautrera. Tu reconnaîtras que
c'est assez dérisoire, comme gain.
Le 23-12-2014, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<549986aa$0$2490$) :Doug713705 , dans le message , a
écrit :+1
Coucou le moyen-âge, ici le XXIe siècle.
Coucou les systèmes vérolés, ici les systèmes sains :)Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste
plus sûr.
Complètement faux. Si ton utilisateur est compromis, utiliser des
commandes n'y fera rien. Il est compromis, point.
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.
Lui fournir des mécanismes lui permettant d'outrepasser des commandes
(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 confondre
progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Le problème de Linux n'est pas tant sa popularisation supposée lui
apporter son lot d'attaques supplémentaires mais bel et bien ce besoin
qu'ont certains de remise en cause des principes de base. Tout ça ruine
tous les efforts antérieurs.
On n'est pas obligé de s'inventer des problèmes pour être heureux ou
"modernes".
XP+FU2 vers la trollosphère.
Le 23-12-2014, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<549986aa$0$2490$426a74cc@news.free.fr>) :
Doug713705 , dans le message <96bombxl8q.ln2@actarus.redatomik.org>, a
écrit :
+1
Coucou le moyen-âge, ici le XXIe siècle.
Coucou les systèmes vérolés, ici les systèmes sains :)
Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste
plus sûr.
Complètement faux. Si ton utilisateur est compromis, utiliser des
commandes n'y fera rien. Il est compromis, point.
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.
Lui fournir des mécanismes lui permettant d'outrepasser des commandes
(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 confondre
progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Le problème de Linux n'est pas tant sa popularisation supposée lui
apporter son lot d'attaques supplémentaires mais bel et bien ce besoin
qu'ont certains de remise en cause des principes de base. Tout ça ruine
tous les efforts antérieurs.
On n'est pas obligé de s'inventer des problèmes pour être heureux ou
"modernes".
XP+FU2 vers la trollosphère.
Le 23-12-2014, Nicolas George nous expliquait dans
fr.comp.os.linux.configuration
(<549986aa$0$2490$) :Doug713705 , dans le message , a
écrit :+1
Coucou le moyen-âge, ici le XXIe siècle.
Coucou les systèmes vérolés, ici les systèmes sains :)Moralité, ne pas utiliser de menus qui utilisent les *.desktop reste
plus sûr.
Complètement faux. Si ton utilisateur est compromis, utiliser des
commandes n'y fera rien. Il est compromis, point.
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.
Lui fournir des mécanismes lui permettant d'outrepasser des commandes
(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 confondre
progrès et nouveauté, vitesse et précipitation, utilité et facilité.
Le problème de Linux n'est pas tant sa popularisation supposée lui
apporter son lot d'attaques supplémentaires mais bel et bien ce besoin
qu'ont certains de remise en cause des principes de base. Tout ça ruine
tous les efforts antérieurs.
On n'est pas obligé de s'inventer des problèmes pour être heureux ou
"modernes".
XP+FU2 vers la trollosphère.
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$) :
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>) :
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$) :
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é.
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é.
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é.
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.
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.
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.
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.
Tu veux tout faire pêter ? ce n'est pas 21 mais 2,21 gigot watts !!!
en plus tu aurait pu fournir la source:
https://www.youtube.com/watch?v=ZECpfQMyJgE
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.
Tu veux tout faire pêter ? ce n'est pas 21 mais 2,21 gigot watts !!!
en plus tu aurait pu fournir la source:
https://www.youtube.com/watch?v=ZECpfQMyJgE
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.
Tu veux tout faire pêter ? ce n'est pas 21 mais 2,21 gigot watts !!!
en plus tu aurait pu fournir la source:
https://www.youtube.com/watch?v=ZECpfQMyJgE
Je plussois totalement ce que dit Doug. Si des personnes se sont cassés la
tête à créer des standard et des système de sécurité simple mais efficace et
légèrement contraignant, ce n'est certainement pas pour emmerder le monde,
mais parce que c'est pertinent. Remettre en cause ces sécurité pour créer
des facilité à la con, reviens simplement à fragiliser le système.
Je plussois totalement ce que dit Doug. Si des personnes se sont cassés la
tête à créer des standard et des système de sécurité simple mais efficace et
légèrement contraignant, ce n'est certainement pas pour emmerder le monde,
mais parce que c'est pertinent. Remettre en cause ces sécurité pour créer
des facilité à la con, reviens simplement à fragiliser le système.
Je plussois totalement ce que dit Doug. Si des personnes se sont cassés la
tête à créer des standard et des système de sécurité simple mais efficace et
légèrement contraignant, ce n'est certainement pas pour emmerder le monde,
mais parce que c'est pertinent. Remettre en cause ces sécurité pour créer
des facilité à la con, reviens simplement à fragiliser le système.
