@starmad88 : reprends le fil... à attaque publique, réponse publique ! Désolé !
fc6 et root ?
Vous êtes deux gamins qui se disputent : "C'est pas moi qui ai commencé, c'est l'autre, c'est pas ma faute à moi" Quand il y a une bagarre, qu'importe celui qui a commencé, les deux se battent.
- Modifié
@starmad88 : c'est mon âme de guerrier... 😉 et je ne supporte pas que des lourds assènent des contre vérités !
Ajout : peut-être est-il possible de déplacer ce thread dans le bistrot...
Ajout : peut-être est-il possible de déplacer ce thread dans le bistrot...
"Redacteurs Wiki", ce seraient pas ces gens super cales qui devraient nous apprndre plein de trucs et montrer l'exemple sur les forums ?
- Modifié
Pas nécessairement, la preuve :
<--------------------------------------------------
:hammer:
<--------------------------------------------------
:hammer:
Ben quoi Yannick, pas d'enervement dans tes propos, pas d'insultes gratuites, un peu d'humour... Si si, tu confirme bien ce que j'ai dit plus haut, TOI... 😉
D'accord, mais est-ce que j'apprends quelque chose (à d'autres personnes), sinon ? :-D
Bizarre quand même que ça dérive autant pour une histoire qui n'aurait quand même pas dut arrivé!
Franchement? c'est pas vrai?
Franchement? c'est pas vrai?
- Modifié
Je trouve rien de bizarre, c'est un combat de ring sur un sujet chaud, et sensible !
Bon, mes doigts ont un peu fourché... Mais bon, c'est pas moi qu'ai commencé... 😉
Cordialement
Ajout : pis ça change des réponses automatiques... 😉
Bon, mes doigts ont un peu fourché... Mais bon, c'est pas moi qu'ai commencé... 😉
Cordialement
Ajout : pis ça change des réponses automatiques... 😉
- Modifié
T'as raison defends-toi !Mais bon, c'est pas moi qu'ai commencé...
Surtout que le mechant herrib il fait rien qu'a t'embeter !
Tu as dit etre le doyen ? On dirait pas 🙁
@bochecha : y avait un clin d'oeil à la fin de mon "c'est pas moi..." , et doyen ça veut pas dire inerte ou modéré !-)
.
Bon une fois la tornade passée, là, explique moi calmement en quoi ca représente une brèche de sécurité çà, parce que je comprends pas du tout:
lrwxrwxrwx 1 root root 16 oct 5 12:37 /etc/alternatives/print-lp -> /usr/bin/lp.cups
$ ls -l /usr/bin/lp.cups
-rwxr-xr-x 1 root root 17948 sep 23 01:18 /usr/bin/lp.cups
on s'occupe pas des droits sur les liens qui n'ont pas de signification ok ? donc ce qui nous occupe c'est bien les droits sur l'exécutable
-rwxr-xr-x 1 root root 17948 sep 23 01:18 /usr/bin/lp.cups
Or partout les droits sur un processus sont ceux de celui qui a lancé la commande non ? donc si la commande est lancée par un user lambda, il n'hérite pas des droits root, il ne pourra pas pour autant aller écrire là où çà lui est interdit ok ? Dans le cas présent il va écrire dans une imprimante que laquelle il n'a que le droit d'usage, sans pouvoir modifier quoique ce soit aux règlages ou autres.
Il en irait tout différenmment si les droits étaient -rwsr-xr-x, car là le trou de sécurité serait béant avec le setuid.
Ou j'ai pas compris ?
Bon une fois la tornade passée, là, explique moi calmement en quoi ca représente une brèche de sécurité çà, parce que je comprends pas du tout:
lrwxrwxrwx 1 root root 16 oct 5 12:37 /etc/alternatives/print-lp -> /usr/bin/lp.cups
$ ls -l /usr/bin/lp.cups
-rwxr-xr-x 1 root root 17948 sep 23 01:18 /usr/bin/lp.cups
on s'occupe pas des droits sur les liens qui n'ont pas de signification ok ? donc ce qui nous occupe c'est bien les droits sur l'exécutable
-rwxr-xr-x 1 root root 17948 sep 23 01:18 /usr/bin/lp.cups
Or partout les droits sur un processus sont ceux de celui qui a lancé la commande non ? donc si la commande est lancée par un user lambda, il n'hérite pas des droits root, il ne pourra pas pour autant aller écrire là où çà lui est interdit ok ? Dans le cas présent il va écrire dans une imprimante que laquelle il n'a que le droit d'usage, sans pouvoir modifier quoique ce soit aux règlages ou autres.
Il en irait tout différenmment si les droits étaient -rwsr-xr-x, car là le trou de sécurité serait béant avec le setuid.
Ou j'ai pas compris ?
Attention il va te répondre que c'est comme ça parce que c'est lui qui le dit et que c'est lui qui a raison parce que c'est lui le plus fort :lol: Pour le moment il n'a pas été capable de nous pondre le moindre argument pertinent. Ne lui en voulons pas, il apprendra l'année prochaine, s'il passe au lycée, comment faire une bonne argumentation.nouvo09 wrote:Bon une fois la tornade passée, là, explique moi calmement en quoi ca représente une brèche de sécurité çà, parce que je comprends pas du tout
PS : Cybervirem, ne me réponds pas que je suis nul que j'y comprends rien, que tu es fort et que tu comprends tout etc... etc... je m'y attends déjà :hammer:
PPS : Je plussoie herrib.
Non, mais ca devrait vouloir dire sage et non pueril...doyen ça veut pas dire inerte ou modéré !-)
Si c'est Aristote qui le dit... 😉L'ignorant affirme, le savant doute, le sage réfléchit. (Aristote)
@nouvo09 :
Déjà fais :
T'imagines néanmoins aisément que c'est pas avec une identité lambda que tu vas écrire sur /dev/lp0...
En outre, le sujet était de gagner l'identité root et les risques liés.
Une commande malicieuse pourrait parfaitement, si pas de selinux, attaquer les .text ou .data du démon, par exemple... et tu lui fais faire autre chose à ton démon... qui est root !
S'il avait appartenu à lp, groupe lp... tu peux faire la même chose mais tu ne gagnes que l'identité lp...
Bon 'chais pas si c'est clair, plus le temps de relire... peut-être ce soir
Cordialement
Déjà fais :
ls -l /usr/sbin/cupsd
-rwxr-xr-x 1 root root 364456 sep 23 01:18 /usr/sbin/cupsdls -l /dev/lp0
crw-rw---- 1 root lp 6, 0 oct 28 08:00 /dev/lp0
ls -l /usr/bin/lp.cups
-rwxr-xr-x 1 root root 17948 sep 23 01:18 /usr/bin/lp.cupsT'imagines néanmoins aisément que c'est pas avec une identité lambda que tu vas écrire sur /dev/lp0...
En outre, le sujet était de gagner l'identité root et les risques liés.
Une commande malicieuse pourrait parfaitement, si pas de selinux, attaquer les .text ou .data du démon, par exemple... et tu lui fais faire autre chose à ton démon... qui est root !
S'il avait appartenu à lp, groupe lp... tu peux faire la même chose mais tu ne gagnes que l'identité lp...
Bon 'chais pas si c'est clair, plus le temps de relire... peut-être ce soir
Cordialement
- Modifié
A BlackDruid et novo009,
La question des impressions est une bonne illustration de la sécurité: il faut écrire dans un répertoire qui est bien protégé mais pour lequel un utilisateur lambda n'a pas les droits utiles. Si on lui confère les droits root, il bénéficierait ainsi de droits allant très au-delà de ce qui est nécessaire pour l'impression. On passe donc pas un utilisateur spécifique, ayant les droits sur le répertoire et sur ce répertoire seulement, et dont l'utilisateur hérite des droits. Et cet utilisateur spécifique n'a pas de shell de connexion en sorte que, si l'on invoque une connexion en son nom, on ne pourra rien en faire. Voilà pour le mécanisme.
La question au point de départ était: connexion en session graphique sous root. Puis elle a dévié en : il n'est pas nécessaire d'avoir un utilisateur root. Puis elle a obliqué encore sur le thème: sur un système bien administré, on n'a pas besoin de root voire d'autres utilisateurs que l'utilisateur principal. Puis elle a encore dévié ... Sans considérer les déclarations à l'emporte-pièce, les affirmations non étayées (cybervirem va maintenant expliquer comme depuis le net on peut voir que root est en session et accéder aux droits root) et j'en passe.
L'effet est effectivement assez négatif mais on ne doit pas supporter les approximations ou oukazes sans explication aucune.
Je regrette simplement d'avoir voulu expliquer pas à pas:
1- que le connexion en session graphique de root ne génère pas en soi de trou de sécurité supplémentaire mais ouvre un risque complémentaire, en particulier quand on utilise des logiciels tels que des navigateurs,
2- que la connexion sous root est quoi qu'il en soit nécessaire à l'administration d'un système et ne doit certainement être proscrite a priori,
3- que de toute façon, un utilisateur root existe ( l'ambiguité des propos tenus par cybervirem... allez, relisez, ça suffira)
4- que des mécanismes complexes sont mis en place pour éviter que des utilisateurs n'héritent de droits root pour certaines tâches (impression, mail sur un système ...) et puissent ainsi, de facto, bénéficier de droits exorbitants compte tenu de ce dont ils auraient effectivement besoin; d'où la création d'utilisateurs spécifiques et j'ai illustré avec l'impression.
Pour le reste, je ne tenterai pas d'expliquer à cybervirem que ses ls -l (sur un /dev ... ça ne signifie pas grand chose ....) ne prouvent rien. Un fichier -une ressource- peut appartenir à root mais cela ne dit certainement pas comment ce fichier peut être exploité. D'ailleurs, si l'on fait ls -l /bin/ls, on trouve:
-rwxr-xr-x 1 root root 93560 sep 28 14:32 /bin/ls
est-ce à dire qu'un utilisateur lambda ne peut pas lancer ls?
Il faut donc expliquer le détail des mécanismes de sécurité, posément et en comprenant préalablement comment cela fonctionne, sans asséner un fatras de têtes de chapitre sans développement .
Nota: pour SELinux. Je lis "Une commande malicieuse pourrait parfaitement, si pas de selinux, attaquer les .text ou .data du démon, par exemple... et tu lui fais faire autre chose à ton démon... qui est root !". D'abord, tous les daemons ne sont pas root fort heureusement (voir l'extrait du /etc/passwd qui montre des daemons ... non root); ensuite SELinux définit à grand trait des ressources pour des programmes. Si ces programmes sont pervertis, ils peuvent parfaitement agir sur leurs ressources sans que SELinux n'y voit rien à redire. Par contre, ils seront confinés et c'est l'apport de SELinux. Voici, de façon rapide, une illustration d'une affirmation mal étayée ... dont un tutorial ne devrait pouvoir s'accommoder.
Je ne répondrai pas à cybervirem, en l'état de ses motivations et quelles que soient ses éructations (les spécimens sont visibles un peu plus haut). Par contre, je répondrai volontiers aux demandes de précisions et remarques de ceux qui ont pris la peine d'argumenter ou questionner.
La question des impressions est une bonne illustration de la sécurité: il faut écrire dans un répertoire qui est bien protégé mais pour lequel un utilisateur lambda n'a pas les droits utiles. Si on lui confère les droits root, il bénéficierait ainsi de droits allant très au-delà de ce qui est nécessaire pour l'impression. On passe donc pas un utilisateur spécifique, ayant les droits sur le répertoire et sur ce répertoire seulement, et dont l'utilisateur hérite des droits. Et cet utilisateur spécifique n'a pas de shell de connexion en sorte que, si l'on invoque une connexion en son nom, on ne pourra rien en faire. Voilà pour le mécanisme.
La question au point de départ était: connexion en session graphique sous root. Puis elle a dévié en : il n'est pas nécessaire d'avoir un utilisateur root. Puis elle a obliqué encore sur le thème: sur un système bien administré, on n'a pas besoin de root voire d'autres utilisateurs que l'utilisateur principal. Puis elle a encore dévié ... Sans considérer les déclarations à l'emporte-pièce, les affirmations non étayées (cybervirem va maintenant expliquer comme depuis le net on peut voir que root est en session et accéder aux droits root) et j'en passe.
L'effet est effectivement assez négatif mais on ne doit pas supporter les approximations ou oukazes sans explication aucune.
Je regrette simplement d'avoir voulu expliquer pas à pas:
1- que le connexion en session graphique de root ne génère pas en soi de trou de sécurité supplémentaire mais ouvre un risque complémentaire, en particulier quand on utilise des logiciels tels que des navigateurs,
2- que la connexion sous root est quoi qu'il en soit nécessaire à l'administration d'un système et ne doit certainement être proscrite a priori,
3- que de toute façon, un utilisateur root existe ( l'ambiguité des propos tenus par cybervirem... allez, relisez, ça suffira)
4- que des mécanismes complexes sont mis en place pour éviter que des utilisateurs n'héritent de droits root pour certaines tâches (impression, mail sur un système ...) et puissent ainsi, de facto, bénéficier de droits exorbitants compte tenu de ce dont ils auraient effectivement besoin; d'où la création d'utilisateurs spécifiques et j'ai illustré avec l'impression.
Pour le reste, je ne tenterai pas d'expliquer à cybervirem que ses ls -l (sur un /dev ... ça ne signifie pas grand chose ....) ne prouvent rien. Un fichier -une ressource- peut appartenir à root mais cela ne dit certainement pas comment ce fichier peut être exploité. D'ailleurs, si l'on fait ls -l /bin/ls, on trouve:
-rwxr-xr-x 1 root root 93560 sep 28 14:32 /bin/ls
est-ce à dire qu'un utilisateur lambda ne peut pas lancer ls?
Il faut donc expliquer le détail des mécanismes de sécurité, posément et en comprenant préalablement comment cela fonctionne, sans asséner un fatras de têtes de chapitre sans développement .
Nota: pour SELinux. Je lis "Une commande malicieuse pourrait parfaitement, si pas de selinux, attaquer les .text ou .data du démon, par exemple... et tu lui fais faire autre chose à ton démon... qui est root !". D'abord, tous les daemons ne sont pas root fort heureusement (voir l'extrait du /etc/passwd qui montre des daemons ... non root); ensuite SELinux définit à grand trait des ressources pour des programmes. Si ces programmes sont pervertis, ils peuvent parfaitement agir sur leurs ressources sans que SELinux n'y voit rien à redire. Par contre, ils seront confinés et c'est l'apport de SELinux. Voici, de façon rapide, une illustration d'une affirmation mal étayée ... dont un tutorial ne devrait pouvoir s'accommoder.
Je ne répondrai pas à cybervirem, en l'état de ses motivations et quelles que soient ses éructations (les spécimens sont visibles un peu plus haut). Par contre, je répondrai volontiers aux demandes de précisions et remarques de ceux qui ont pris la peine d'argumenter ou questionner.
Bon, je débarque, j'ai pas le courage de lire ...
Ce que je retiens de la première page :
- riri est un c** (vu le respect qu'il a des autres, je me permets de ne pas le respecter). Et pars sous Edgy, Fedora n'a pas besoin de gens comme toi.
- pour l'histoire de la connexion root, pour moi "on ne doit pas se connecter en graphique en root", c'est une déformation du Windowsien de base. Allez voir, même si sous Vista ils mettent des utilisateurs par défaut, les gens raleront parce qu'on leur demandera un mdp et se foutront les droits super utilisateurs...
Est ce que ça rend le pc plus vulnérable aux attaques extérieures : j'en sais rien, je ne suis pas un expert en sécurité
- remarque perso @ cybervirem : je pense que maintenant tu peux te passer du "Hi ... cordialement", c'est un forum internet 😉
Ce que je retiens de la première page :
- riri est un c** (vu le respect qu'il a des autres, je me permets de ne pas le respecter). Et pars sous Edgy, Fedora n'a pas besoin de gens comme toi.
- pour l'histoire de la connexion root, pour moi "on ne doit pas se connecter en graphique en root", c'est une déformation du Windowsien de base. Allez voir, même si sous Vista ils mettent des utilisateurs par défaut, les gens raleront parce qu'on leur demandera un mdp et se foutront les droits super utilisateurs...
Est ce que ça rend le pc plus vulnérable aux attaques extérieures : j'en sais rien, je ne suis pas un expert en sécurité
- remarque perso @ cybervirem : je pense que maintenant tu peux te passer du "Hi ... cordialement", c'est un forum internet 😉
merci temet de confirmer ce que j'ai dit plus haut!
Mais bon! pour faire simple et sans bavure! prenez une voiture! vous ne la fermer pas à clef parfois parce que c'est plus simple pour, par exemple, sortire vos courses! mais si vous la laissez ouverte tout le temps c'est plus simple pour vous la faire voler ou autre... c'est déjà dur même fermer alors ouverte...
J'espère que cette image vous aidera à faire la lumière sur cette histoire!
Comme quoi pour expliquer des choses complexe il faut parfois des explications simple!
Sur ce Bonne nuitée @ tous!
Mais bon! pour faire simple et sans bavure! prenez une voiture! vous ne la fermer pas à clef parfois parce que c'est plus simple pour, par exemple, sortire vos courses! mais si vous la laissez ouverte tout le temps c'est plus simple pour vous la faire voler ou autre... c'est déjà dur même fermer alors ouverte...
J'espère que cette image vous aidera à faire la lumière sur cette histoire!
Comme quoi pour expliquer des choses complexe il faut parfois des explications simple!
Sur ce Bonne nuitée @ tous!
- Modifié
@Temet : bof, j'aime bien le Hi, Cordialement...
@herrib : toujours n'importe quoi, hors sujet, long et qui ne veut rien dire ! On t'a pas demandé de faire une intro sur l'admin ni ton mea culpa. Je te dis simplmenet que la sécurité n'est pas à ta portée et sur un système bien configuré ls appartient à wheel par exemple ! J'attends de voir ton tuto histoire de rigoler... N'oublie pas, c'est quand tu veux, tu fais l'admin et je fais le pirate... en réseau local bien sûr... Tu veux pas jouer histoire de vraiment montrer tes compétences ? Par exemple, lors d'une install partie, un petit stand pour interesser les grands...
@herrib : toujours n'importe quoi, hors sujet, long et qui ne veut rien dire ! On t'a pas demandé de faire une intro sur l'admin ni ton mea culpa. Je te dis simplmenet que la sécurité n'est pas à ta portée et sur un système bien configuré ls appartient à wheel par exemple ! J'attends de voir ton tuto histoire de rigoler... N'oublie pas, c'est quand tu veux, tu fais l'admin et je fais le pirate... en réseau local bien sûr... Tu veux pas jouer histoire de vraiment montrer tes compétences ? Par exemple, lors d'une install partie, un petit stand pour interesser les grands...
Eh ! Ca y est je suis root là ! Vas-y fais toi plaisir :hammer:cybervirem wrote:- se connecter root implique la possibilité d'utiliser ta machine à ton insu !
- si si, la connexion root, vue du net permet nombre de possibilités !