Devant le mal que j’ai à trouver de bons tutos sur Linux, surtout sur ce que je cherche, j’ai fait quelques manips.
J’ai ainsi pu me rendre compte par moi même que seul root est capable d’ajouter et supprimer un utilisateur (je pense que c’est pareil pour un groupe). Il est aussi le seul à pouvoir modifier le propriétaire d’un fichier.
Par contre, je n’explique pas comment un exécutable (au sens large je crois, mais je vise les daemons), sont capables de prendre une “identité”. Je m’explique : lorsque je tape apt-get apache2, apache2 s’installe. Donc déjà, il a eu les droits pour le faire. J’imagine que c’est parce que je l’ai installé alors que j’étais connecté sous Root. Deuxio, il créé un utilisateur 33 et un groupe 33. Ce qui m’interpèle aussi. De quel droit ? A partir du moment où j’appelle apt-get depuis root, tout se fait sous root ?
Deuxio, le daemon Apache2 se lance sous root. Là est la question la plus “grave” : de quel droit ? Qui lui a permis - qu’est-ce qui lui permet ? De plus, il “décide” de démarrer un nouveau processus sous www-data (33) … qu’est ce qui lui permet ? (là, je pense que s’il est en root, il peut le faire du coup). C’est d’autant plus flagrant avec un serveur ftp : il suffit dans le fichier conf de lui dire d’être le proprio x, et il créé des fichiers sous x.
Mon hypothèse est que Apache2 lance un processus sous root parce que son fichier executable a comme propriétaire root. Je n’ai pas essayé de changer son propriétaire (pas encore du moins). Mais si oui, cela veut-il dire que si je mets un propriétaire arbitraire, il se lancera sous ce propriétaire ? De façon plus globale, lorsqu’un executable se lance (je n’y connais rien mais il me semble que je peux créer un fichier avec du code python par exemple, et le lancer … dites moi si je me trompe), il se lance sous le propriétaire qui le possède ? Et il ne se lance que si il est “executable”, chmod “x” pour le propriétaire ou le groupe que celui qui le lance possède ?
Les réponses m’avanceraient, car elles me permettraient, je pense, de mieux comprendre les techniques de sécurisation, que je considère pour le coup, comme des techniques de base, des fichiers. D’une certaine façon, savoir que Pureftpd se lance sous root me fait penser que la moindre faille exploitable donne l’opportunité d’execution de commandes shell (encore une fois, le terme est employé vite) sous root. L’étape suivante de sécurisation, que je n’essaierai pas d’aborder, serait effectivement de trouver un moyen de le bloquer, d’où l’existance des chrootages d’exécutables voire la modification d’un processus après démarrage, une fois les ports ouverts (faut-il être root pour ouvrir un port ?) etc etc.
Me conseiller un tuto là dessus n’est pas de refus, car je le répète : ce n’est pas faute de faire des recherches avant, mais je ne vois que des articles sur le chmod …
Je pense que tu peux consulter le wiki (clic en haut à DR), tu y as toutes les explications à tes questions.
Pour commencer, tu peux partir du principe que ‘root’ c’est Dieu et qu’il peut tout faire.
[quote]Pour commencer, tu peux partir du principe que ‘root’ c’est Dieu et qu’il peut tout faire.
[/quote]
C’est vrai dans le cas d’un système classique, mais ça ne l’est plus si on met en place un système de droits avancés comme SELinux. Mais pour ne pas embrouiller notre ami débutant nous partirons du principe qu’effectivement “root” a théoriquement tous les droits et peut donc absolument tout faire.
Effectivement. C’est à l’administrateur de la machine que revient la décision et donc le droit de définir qui est en droit d’avoir accès (et donc un compte) à la machine.
Non. “root” a tous les droits, donc il peut modifier le propriétaire, le groupe et les droits de n’importe quel fichier.
Mais un propriétaire peut également donner un de ses fichiers à un autre utilisateur (logique en fait). Par contre impossible de s’approprier un fichier dont on n’est pas propriétaire… (logique encore une fois).
Quant aux droits, un utilisateur ne pourra modifier les droits que s’il a des pouvoirs dessus. Donc s’il n’est pas propriétaire et qu’il ne fait pas partie d’un groupe, il ne sera pas en mesure de modifier les groupes du propriétaire/du groupe/du public. Là encore c’est le bon sens qui a été retenu comme principe.
Absolument, tu as bien compris. Comme tu es en “root”, tout ce que tu fais hérite des droits de l’utilisateur sous lequel tu es connecté (sauf dans le cas du setuid et du setgid, ce sont des droits qui permettent de prendre une autre identité lors de l’exécution d’un fichier), et donc dans ton cas le programme aura les droits “root” !! Ce qui signifie que si le programme est buggué et (par exemple) se met à supprimer des fichiers système qu’il n’aurait pas dû, il aura tous les droits pour le faire… Voilà pourquoi on recommande de faire un minimum de chose sous l’identité “root”. La moindre erreur peut être fatale pour tout le système.
Oui, comme je viens de te l’expliquer. C’est d’ailleurs pour ça que la majorité des programmes requièrent les droits “root” pour pouvoir s’installer convenablement.
Les démons se lancent en général au démarrage via les fichiers “*rc” (voir “runlevels” pour plus d’info). Or, ces fichiers sont des scripts système exécutables qui sont lancés au démarrage de la machine par le système, donc avec les droits “root”. Ainsi, lorsqu’ils lancent les démons, les démons héritent des droits “root”.
[quote]De plus, il “décide” de démarrer un nouveau processus sous www-data (33) … qu’est ce qui lui permet ? (là, je pense que s’il est en root, il peut le faire du coup). C’est d’autant plus flagrant avec un serveur ftp : il suffit dans le fichier conf de lui dire d’être le proprio x, et il créé des fichiers sous x.
[/quote]
En schématisant : tu appuies sur le bouton ON de ton ordi, ce qui lance le BIOS, qui lance le boot manager, qui lance le kernel (qui est “root” puisque c’est le système de base), qui lance les scripts de démarrage en “root”, qui lancent les démons en “root”, ce qui permet aux démons de lancer n’importe quel processus sous n’importe quelle identité. Voilà en (très) gros la séquence de démarrage du système.
[quote]Mon hypothèse est que Apache2 lance un processus sous root parce que son fichier executable a comme propriétaire root. Je n’ai pas essayé de changer son propriétaire (pas encore du moins). Mais si oui, cela veut-il dire que si je mets un propriétaire arbitraire, il se lancera sous ce propriétaire ? De façon plus globale, lorsqu’un executable se lance (je n’y connais rien mais il me semble que je peux créer un fichier avec du code python par exemple, et le lancer … dites moi si je me trompe), il se lance sous le propriétaire qui le possède ? Et il ne se lance que si il est “executable”, chmod “x” pour le propriétaire ou le groupe que celui qui le lance possède ?
[/quote]
Tu as bien compris.
Si un processus “aze” est lancé sous l’identité “moimoi”, alors “aze” possède les droits de “moimoi” (et les droits des groupes rattachés à “moimoi”).
Pour lancer un processus, “moimoi” doit posséder le droit “x” sur le fichier, ou à défaut faire partie du groupe du fichier avec le droit “x” activé pour le groupe en question sur ce fichier (je ne sais pas si je suis clair là…).
Le tuto que je t’ai passé devrait bien t’aider.
Sinon tu as toujours la commande miracle, celle qui permet d’afficher le manuel :
C’est le gros problème d’un système Linux classique (et de Windows, mais faut-il le préciser ?). C’est pour ça que la NSA a mis au point SELinux qui est un module supplémentaire qui permet de restreindre les droits selon une politique de sécurité définie (ce dont j’ai parlé au tout début). Et là on renforce considérablement la sécurité du système Linux puisque même “root” doit s’astreindre à la politique de sécurité définie dans SELinux.
[quote]L’étape suivante de sécurisation, que je n’essaierai pas d’aborder, serait effectivement de trouver un moyen de le bloquer, d’où l’existence des chrootages d’exécutables voire la modification d’un processus après démarrage, une fois les ports ouverts (faut-il être root pour ouvrir un port ?) etc etc.
[/quote]
Si tu souhaites administrer un parc informatique sensible qui protège des brevets de grande valeur ou que tu aimes la sensation des coups de barbelé, tu peux te tourner vers SELinux. Il y a cependant des systèmes moins contraignants comme AppAmor. A noter qu’AppArmor fait partie intégrante du noyau Linux depuis la version 2.6.36, c’est donc celui que je recommanderais en priorité.
Maintenant si c’est pour sécuriser des postes classiques qui ne contiennent pas des données spécialement sensibles, une bonne approche consiste à mettre en place des groupes et à bien les administrer avec les droits nécessaires et suffisants.
Tu peux y associer les ACL (Access Control List) qui permet d’affiner les droits des systèmes de type UNIX (ce qui est réellement intéressant lorsqu’on gère beaucoup d’utilisateurs, si c’est pour ta machine perso les droits de bases devraient déjà largement te suffirent).
[quote]Me conseiller un tuto là dessus n’est pas de refus, car je le répète : ce n’est pas faute de faire des recherches avant, mais je ne vois que des articles sur le chmod …
[/quote]
C’est fait
bjr outre la doc sur le wiki ici present il y a aussi les documentations sur ubuntu qui different tres peu puisque basées sur debian (sauf le sources.list et les preferences bien sur)
De plus, la doc php indique que seul root peut changer les propriétaires. De façon générale, si un système tel que CGI sous environnement suEXEC ou je sais pas quoi fait que Apache lance un processus sous l’utilisateur du propriétaire du fichier appelé, il suffirait à Monsieur hébergé mutualisé x de faire un chmown de ses fichiers vers l’utilisateur y pour pouvoir lancer ses fichiers php sous le propriétaire y et avoir accès aux fichiers de Monsieur y. Ce qui va à l’encontre de ce système, je trouve … Même si des open_basedir interviennent, ce n’est pas une raison …
Ensuite, je suis pas sûr du coup d’avoir compris … Un executable s’execute sous le propriétaire enregistré dans ses droits, ou sous le propriétaire qui l’a démarré ? Car Cluxter, si j’ai bien compris, tu as dit que les init.d sont lancés par Kernel, donc par root, et que du coup ils sont root. Tu n’as pas dit que c’était lié au fichier.
Hier, j’ai rée un fichier python sous pascalous, et je l’ai lancé : la commande TOP m’a bien affiché un processus sous l’utilisateur pascalous. Mais … je l’ai créé avec pascalous et l’ai lancé depuis pascalous. Il aurait fallu que je teste la création et la modification avec l’un et l’autre (pascalous / root).
Je vais voir la doc, je vous tiens au “jus”, surtout que l’histoire des setuid m’intrigue …
Apache est lancé en root car il est lancé par root, pas parce que le fichier appartient à root. Ainsi, il peut utiliser les droits root si besoin (ouverture du port 80, écriture dans les logs, suexec/suphp,…) et créé un « sous-processus » lancé par l’utilisateur www-data. Ainsi, si quelqu’un arrive à exploiter une faille d’apache, il n’aura que les droits de www-data.
Hmm … j’etends surtout s’il arrive a exploiter les failles du processus ouvert sous www-data. On est d’accord. Par contre, et ca explique les solutions d’hyper sécurisation, une faille exploité sur le processus principal (je crois le daemon), serait catastrophique.
Hmmm … je ne sais pas où tu veux en venir mais, je vais étendre :
mkdir /pascalous
chown pascalous:pascalous /pascalous
Donc, directement à la racine. Je ne veux pas vous contredire sur un sujet que vous connaissez mieux que moi, mais je reste septique sur le changement de propriétaire. En même temps, que pascalous veuille rendre Momo comme propriétaire de son fichier, je ne vois rien d’illogique … mais je vois surtout ça par rapport au mode php CGI (enfin, plus précisemment suExec etc) qui crée un processus Apache sous le même utilisateur que le propriétaire de fichier. Mais il y a (forcément) quelque chose qui m’échappe.
A savoir que pascalous n’a été créé sur le serveur que pour utilisateur de connexion SSH. C’est le seul autorisé, il ne possède pas de dossier personnel, et à priori, aucun fichier. Peut-être le changement de propriétaire ne peut se faire par un utilisateur lamba qu’au sein de son propre dossier utilisateur.
Totalement. C’est ce qui est le plus redouté sous Linux, une faille dans un processus exécuté sous l’identité “root”. Si on peut exécuter une commande arbitraire dans un tel processus, alors tout le système tombe (sauf avec les contrôles d’accès obligatoires [abrégé MAC en anglais pour Mandatory Access Control] comme SELinux, AppArmor,…).
Je veux en venir de te rappeler qu’à la racine tu n’es pas chez toi mais chez root (racine) et que donc pas plus que tu n’as eu le droit de le créer tu n’as le droit de le changer de propriétaire
Je veux en venir de te rappeler qu’à la racine tu n’es pas chez toi mais chez root (racine) et que donc pas plus que tu n’as eu le droit de le créer tu n’as le droit de le changer de propriétaire [/quote]
Ta démarche est certainement pédagogique, mais c’est un serveur global … tous les utilisateurs sont donc moi en quelque sorte …
C’est simple à savoir : regarde les droits attribués à ton programme “chown” sur ton système. Rien ne t’empêche d’autoriser ou d’interdire tous les utilisateurs à exécuter chown. Et setuid/setgid peut encore modifier la donne.
Après il a y des programmes qui en étant exécutés par un utilisateur demanderont les droits root, mais ils le demanderont explicitement lorsqu’on tentera de les lancer en tant qu’utilisateur.
chown est binaire. Sinon ses droits sont 755 root:root
Tous les utilisateurs, à priori, sont capables de l’exécuter. D’ailleurs, il reconnait bien la commande quand je ne suis pas dans root, mais il me la refuse (operation not permitted).
Je regarderai pour les setuid je ne vois pas pour l’instant où on peut lui dire (de mémoire, tu avais dit ou j’avais lu que cela permettait à un fichier de s’executer toujours sous le meme utilisateur, quelque soit l’utilisateur l’executant en shell).
Je regarderai, mais à priori, si je tape “apache2 machin” dans la console, une commande s’execute. Or, la commande n’est pas présente dans le fichier conf de bash. Donc, est-ce comme sous Windows, si je veux que mon fichier “momo” soit executé en tapant simplement “momo” dans bash par exemple, je n’ai qu’à enregistrer son dossier dans PATH ? La réponse est presque certaine “oui”
Tu avais dit que Kernel executait les daemons sous root (sous lui-même qui a les pleins pouvoir quoi ^^). J’ai donc cherché à savoir si le plus simplement du monde, tout fichier présent dans init.d serait executé au démarrage de la machine, et si executé sous root.
[quote]init est le premier processus, exécuté par le noyau, qui est père de tous les autres (son PID est donc 1).
Au démarrage, il lance divers scripts contenus dans /etc/init.d/ ou /etc/rc*.d/.
C’est dans le dossier /etc/init.d qu’il faut enregistrer les fichiers à lancer au démarrage. [/quote]
Cette citation semble confirmer mon hypothèse. Donc, si je crée un fichier python dans init.d, sans aucun enregistrement nul part, il sera bien lancé au démarrage de la machine, sous root ? Par contre, n’y a t-il pas d’ordre de priorité (peut-être qu’un executable a besoin qu’un autre daemon soit déjà lancé … ou le lance-t-il lui même à ce moment là ?).
Merci pour vos aides, en complément des lectures que je fais, je crois que je commence à bien cerner certaines choses sur Linux, ce qui m’aide dans ma découverte ;o
suExec etc) qui crée un processus Apache sous le même utilisateur que le propriétaire de fichier. Mais il y a (forcément) quelque chose qui m’échappe.