Logiciel : Le noyau Linux 2.6.25 est disponible
Posté par patrick_g (page perso, ). Modéré le 17 avril 2008.
Peu avant la sortie du 2.6.24 les divers mainteneurs des sous-systèmes ont indiqués sur la liste de diffusion du noyau leurs intentions sur les patchs suffisamment stables pour pouvoir migrer de la branche de test d'Andrew Morton (la -mm) vers la branche de Linus. La période d'intégration de ces milliers de patchs doit durer deux semaines et elle permet l'ajout de toutes les nouveautés prévues dans le nouveau noyau.
Cette fois-ci le démarrage a été rendu un peu plus lent car la plupart des développeurs participaient à la conférence Linux en Australie à la fin du mois de janvier. Une fois la fenêtre d'intégration d'environ quinze jours refermée la saga des "releases candidates" a pu commencer.
![[en]](../images/en.png)
Les nouveautés du noyau 2.6.25 (3384 hits)-
Le bilan des ajouts partie 1 (508 hits)
-
Le bilan des ajouts partie 2 (324 hits)
-
Le bilan des ajouts partie 3 (331 hits)
-
Les prévisions pour l'avenir de Linux (1172 hits)
> Lire la dépêche (134 commentaires, moyenne: 4,1).
Vous avez demandé le commentaire #925273.
Run by 
Cette page a été générée par Templeet en 0.0954s (dont 0.0087 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
SMACK
Dépêche impeccable.
Il n'y a qu'un truc qui m'énerve.
> Le module SMACK (Simplified Mandatory Access Control Kernel) a été ajouté au noyau 2.6.25 afin d'offrir une alternative simplifiée à SELinux.
Au lieux de "alternative simplifiée à SELinux", pourquoi pas un "système simple de protection" ?
> SELinux est un module très puissant mais il est malheureusement assez complexe à configurer et à gérer au quotidien.
Ceci est une sorte d'incompréhension de l'objectif de SELinux.
Maîtriser SeLinux est très très complexe. Mais pour l'utilisateur final et avec une bonne intégration de SeLinux ce n'est pas le cas.
Aujourd'hui il y a de nombreux utilisateurs avec SeLinux et ils n'y pensent quasiment jamais. Enfin c'est une très mauvaise idée de demander à l'utilisateur de bidouiller avec la sécurité.
> En dépit des efforts méritoires de ses promoteurs pour simplifier son utilisation au fil du temps
Ces efforts ne sont pas terminés.
Il y a SeLinux et les règles SeLinux. Fedora utilise les règles NSA qui sont les plus complètes et les plus fines (il y a aussi les règles mls pour le "workflow"). Elles sont complexes car le défit sécurité est complexe. Elles ne le sont pas d'elle même. Il y a un autre projet qui offre des règles simplifiées (désolé, j'ai oublié le nom de ce projet).
SMACK ne prétend pas simplifier SeLinux (et ses règles NSA). Il y a des choses qu'on peut faire avec SeLinux et qu'on ne fera jamais avec SMACK. SMACK a une autre approche, d'autres objectifs.
Au "désespoire" des développeurs SeLinux, SMACK a été intégré. Il faut donc se trainer LSM. M'enfin, il n'y a pas de problème bloquant SMACK qui est bien conçu (contrairement à AppArmor). Linus a fait un choix, techniquement son choix est irréprochable.
> Ces derniers ont exercé une pression afin qu'une solution plus simple apparaisse et SMACK est le résultat de cette pression.
Ces derniers qui ne doivent probablement pas utiliser SeLinux...
Et pression sur qui ?
SMACK n'est pas lié a des pressions. SeLinux n'existerait pas, il y aurait peut-être SMACK. La sortie de SMACK ne remet pas en cause SeLinux (et ses règles NSA).
SeLinux est un projet très ambitieux et il y a des trucs sucks encore. Mais ça s'arrange.
> Les développeurs de SELinux, qui étaient jusqu'à présent les seuls utilisateurs de l'infrastructure LSM, ont opposé une âpre résistance à l'inclusion de SMACK dans le noyau.
Je n'ai pas suivit en détail les discussions. Mais elles ne portaient sur des problèmes techniques qu'a SMACK. Mais plus globalement sur la gestion du projet Linux. Ce que fait SMACK, SeLinux peut le faire. SMACK fait donc un peu doublon avec SeLinux et c'est malheureux.
> Quand je verrai les spécialistes de la sécurité utiliser des arguments rationnels et se mettre d'accord sur un truc les choses changeront peut-être. Mais franchement je m'attends à ce que l'enfer gèle et que les cochons nichent dans les arbres avant que cela n'arrive. Mais bon, je peux toujours espérer.
Si j'ai bonne mémoire, c'était surtout par rapport à AppArmor vs SeLinux. Globalement SMACK et SeLinux pour les aspects techniques sont sur la même longueur d'onde et SMACK ne prétend pas remplacer SeLinux. L'auteur de SMACK a aussi dit qu'il bosserait sur SeLinux si LSM était abandonné.
Linus estime qu'il n'y a pas qu'une approche pour la sécurité et donc qu'il doit garder LSM.
> Toute cette controverse a fait l'objet d'un article détaillé du site Linux Weekly News.
Et la contreverse porte plus sur LSM que sur SMACK vs SeLinux. La contreverse est LSM.
[^]Re: SMACK
> Aujourd'hui il y a de nombreux utilisateurs avec SeLinux et ils n'y pensent quasiment jamais.
Il y a quelques chiffres sur smolts depuis peu. Mais ils me sont pas très claires :
http://smolts.org/static/stats/stats.html (onglet selinux)
Disons qu'une bécane sur 4 a selinux en mode "enforcing".
> Il y a un autre projet qui offre des règles simplifiées (désolé, j'ai oublié le nom de ce projet).
C'est Seedit :
http://seedit.sourceforge.net/
[^]Re: SMACK
Disons qu'une bécane sur 4 a selinux en mode "enforcing".
Et 50%~ de désactivé.
You got the money, I got the soul.
[^]Re: SMACK
>>> Il y a quelques chiffres sur smolts depuis peu. Mais ils me sont pas très claires :
Disons qu'une bécane sur 4 a selinux en mode "enforcing".
Une bécane sur 4 ayant smolt d'installé !
Comme smolt est un outil Fedora et que Fedora pousse SELinux on ne peux pas dire que ce soit représentatif des machines Linux en général.
[^]Re: SMACK
> Comme smolt est un outil Fedora et que Fedora pousse SELinux on ne peux pas dire que ce soit représentatif des machines Linux en général.
Certe. Mais RHEL est la distribution entreprise la plus utilisée et elle a SeLinux activé par défaut (depuis RHEL 4). Pour un serveur, SeLinux ne va pas être désactivé à la légère. Donc il ne serait vraiment pas étonnant que plus de 80 % des RHEL aient SeLinux d'activé (et en mode enforcing). Et tout cas très probablement plus de 50 %.
[^]Re: SMACK
En passant, SeLinux est très certainenement le système de sécurité le plus utilisé. Il a aussi sans problème la plus grosse communauté derrière lui et il est le plus perfectionné.
Bref, il serait très hazardeux de qualifier SeLinux d'échec même s'il n'est pas sur 50 % des postes.
Ce qui est dommage est que SeLinux demande un gros effort pour être exploitable dans une distribution. Cet effort il n'y a pratiquement que Red Hat/Fedora qui l'a fait. Les autres distributions ne sont pas dans un état qui permet d'avoir SeLinux activé par défaut. M'enfin, c'est aussi presque un choix des autres distributions.
[^]Re: SMACK
>>> En passant, SeLinux est très certainenement le système de sécurité le plus utilisé
En passant c'était le seul système de sécurité disponible en mainline jusqu'à présent. Pas étonnant qu'il soit le plus utilisé ;-)
>>> Bref, il serait très hazardeux de qualifier SeLinux d'échec
Je n'ai jamais écrit ça et j'ai même pris grand soin de dire que SELinux était plus puissant et plus complet et que ses devs bossaient dur sur la simplification de son utilisation.
Personne de dit que SELinux est un échec. Au contraire.
[^]Re: SMACK
> Je n'ai jamais écrit ça
Oui.
Ta dépêche est d'excellente qualité.
Je trouvais dommage que tu insistes sur une sorte de combat entre Smack et SeLinux. Tu as probablement remarqué que SeLinux critique très peu Smack et qu'il est même bien jugé. On avait eu des critiques au vitriol pour AppArmor. Ce n'est absolument pas ça pour Smack. Ce qui montre bien que les critiques anti-AppArmor n'était pas un "tout sauf SeLinux".
Enfin il ne faut pas croire que SeLinux est uniquement préoccupé par SeLinux. SeLinux est préoccupé par la sécurité sous Linux (où il reste encore beaucoup a faire dans le desktop). Si Red Hat (et d'autres) prend SeLinux, ce n'est pas pour SeLinux, mais pour avoir un bon niveau de sécurité sous Linux. Donc SeLinux, et plus largement ceux qui veulent un bon niveau de sécurité sous Linux, ne veulent pas de LSM car c'est très pénalisant. SeLinux n'est pas contre Smack. Ce dernier a été très peu critiqué (voire pas du tout). SeLinux est contre LSM (et depuis bien avant Smack ou que AppArmor devienne vaguement populaire).
On a eu un SeLinux vs AppArmor et plus largement un "système de sécurité bien conçu" vs "système de sécurité qui veut seulement être populaire". On n'a pas de SeLinux vs Smack. Mais ta dépêche n'est presque que sous cet angle (pression, Smack car Selinux, etc). Je pense que c'est une erreur d'avoir présenté les choses sous cet angle.
Ceci dit, je ne doute pas de ton honnèteté et je ne pense pas un instant que tu avais des arrières pensées "machiavéliques".
[^]Re: SMACK
>>> Donc SeLinux, et plus largement ceux qui veulent un bon niveau de sécurité sous Linux, ne veulent pas de LSM car c'est très pénalisant.
Sauf que Linus a décrété que LSM resterait dans le noyau car il pense que les devs spécialistes de sécurité ne sont jamais d'accord entre eux (et il a pas tort sur ce point).
LSM est là pour permettre à différentes solutions de cohabiter.
A noter qu'aujourd'hui un article sur TOMOYO est présent sur le site LWN.
TOMOYO est, comme l'était AppArmor, basé sur le pathname ce qui va sans doute provoquer des hurlements du coté des devs SELinux. On verra bien ce qui va se passer pour l'inclusion en mainline ou pas.
Je ne sais pas si tu est abonné à LWN alors je te colle un extrait :
"Casey Schaufler's persistence finally resulted in the merging of the SMACK security module for 2.6.25; it is the only such module, other than SELinux, ever to get into the mainline. Now that SMACK has paved the way, talk of removing the LSM framework (which had been strongly vetoed by Linus in any case) has ended and the next security module should have an easier time of it.
Linus has also decreed that pathname-based security modules are entirely acceptable for inclusion into the kernel."
[^]Re: SMACK
> Sauf que Linus a décrété que LSM resterait dans le noyau
Et comme j'ai dit, si c'est pour avoir SeLinux et Smack, c'est techniquement logique. Ces derniers étant respectés par les experts en sécurité (et les experts SeLinux respectent Smack et vice versa). Dans une politique à long terme, c'est plus discutable (James Morris l'a très bien expliqué).
> car il pense que les devs spécialistes de sécurité ne sont jamais d'accord entre eux
Mais lesquels ?
Ceux qui comme Linus s'y intéresse quasi jamais ?
Linus a au moins le mérite de le reconnaitre. En passant Linus dit que SeLinux est la première chose qu'il vire sinon rien ne marche (selon lui) et ne manque pas une occasion pour critiquer SeLinux. Mais il a installé une F9 pour sa femme avec SeLinux activé (et en mode enforcing) sans s'en rendre compte...
Quels experts en sécurité ?
Ceux qui se proclament expert car ils trouvent l'interface graphique d'AppArmor séduisante ?
Smack prouve que Linux a des vrais experts en sécurité. Pas des experts qui ne sont que pro SeLinux (ou que pro-AppArmor).
> Linus has also decreed that pathname-based security modules are entirely acceptable for inclusion into the kernel.
On peut trouver une tripoté de grand nom de Linux qui sont contre cette idée. Dont Alan Cox par exemple.
Pour ma part je pense que Linus a manqué de courage en gardant LSM (c'est un demi reproche).
Et actuellement, même si AppArmor a fait beaucoup de bruit, il n'y a pratiquement que SeLinux qui tient la roule : expertise, communauté, niveau d'utilisation/support par les distributions qui ont eux la volonté de l'utiliser (RHEL et Fedora ce n'est pas rien, et Ubuntu va peut-être y venir).
Linus a décidé de laisser la compétition ouverte. M'enfin, pour les systèmes a usage général SeLinux a déjà quasi gagné. Smack sera peut-être utilisé pour l'embarqué et d'autres systèmes spécifiques.
En passant, il serait bien d'éviter l'anti-SeLinux primaire. Je viens d'avoir l'impression que tout ce qui dérange SeLinux te fait plaisir...
Je ne fais pas d'anti-Smack primaire. Par contre je suis clairement anti-AppArmor.
[^]Re: SMACK
>>> En passant, il serait bien d'éviter l'anti-SeLinux primaire. Je viens d'avoir l'impression que tout ce qui dérange SeLinux te fait plaisir...
Bof non je m'en fous je ne l'utilise pas. Maintenant si Debian/Ubuntu arrivent à l'intégrer et à en simplifier l'utlisation (en reprenant peut-être des outils RedHat) alors je l'utiliserai volontiers car c'est toujours bien d'avoir une machine mieux sécurisée.
Ce qui m'a un peu étonné c'est l'attitude de James Morris sur la lkml qui donnait vraiment l'impression de vouloir barrer l'inclusion de tous les concurrents de SELinux. Je n'ai pas la moindre compétence pour juger techniquement ses arguments mais à le lire on se dit "Ce mec se bat pour sa chapelle ce qui me rend soupçonneux pour ses arguments".
>>> Par contre je suis clairement anti-AppArmor.
Est-ce que tu est assez calé techniquement pour vraiment juger de la qualité d'AppArmor ? A lire les articles sur le net on comprend qu'AppArmor est moins bien/moins sécurisé que SELinux...mais il est aussi beaucoup plus simple. Peut-être a-il sa place en tant que solution "pas parfaite mais bien suffisante pour la majorité des gens" ?
Moi j'en sais rien donc je n'en pense rien. Je me contente de regarder les gens débattre.
[^]Re: SMACK
> Est-ce que tu est assez calé techniquement pour vraiment juger de la qualité d'AppArmor ?
Non. Mais j'ai lu une série de 4 (ou 5) articles sur AppArmor (comparé à SeLinux). Des articles très techniques et parfaitement argumentés. J'ai la flemme de les chercher, désolé.
> A lire les articles sur le net on comprend qu'AppArmor est moins bien/moins sécurisé que SELinux...mais il est aussi beaucoup plus simple.
Ce n'est pas la simplicité de AppArmor qui m'énerve, c'est sa façon simpliste, voire marketing, de faire de la sécurité. Par exemple l'auto-apprentissage est de la connerie. Il implique une mauvaise pratique de la sécurité. C'est séduisant, mais c'est de la connerie.
Unix (et donc Linux) a toujours été le développement de solution juste même si c'est long et difficile. Unix ne cède pas à la facilité comme peut le faire Windows (d'où les anti-virus, d'où les 50 000 options pour "sécuriser", etc).
Avec AppArmor on cède à la facilité pour ne pas dire l'audimat. Cette dérive est inquiétante.
> Peut-être a-il sa place en tant que solution "pas parfaite mais bien suffisante pour la majorité des gens" ?
C'est non (sauf système spécifique avec un admin qui sait ce qu'il fait). Les protections Unix classiques, c'est "pas parfaite mais bien suffisante pour la majorité des gens" ? Mais dans ce cas, es-ce que les gens bidouilles avec les protections classiques où es-ce qu'il font confiance (dans la limite de ses capacité) aux protections classiques ?
Ce n'est pas car on a un système de protection, que pour mieux se protéger le premier venu doit le bidouiller. Comme pour le système de protection classique, ce qui est fournit doit être OK et on n'a pas à y toucher sauf cas exceptionnel. Il est OK car des experts ont bossé dessus. SeLinux c'est parail. SeLinux (avec ses règles) est fait pour marcher de suite et sans bidouiller (sauf cas très particulier).
Ce que fait AppArmor, c'est séduire les gens en disant "Vous allez sécuriser Votre système". Mais ce n'est pas de ça qu'a besoin Linux ni aucun système. Ce type de truc, c'est du Windows avec 50 000 options pour "sécuriser" + un abonnement à un anti-virus. Une fois que t'as installé ton anti-virus et fouillé toutes les options de IE, t'es super content, t'as sécurisé ta bécane. C'est flatteur. Que voit-on dans la pratique ? Ben que compter sur l'utilisateur pour sécuriser une bécane est une très mauvaise idée. Que c'est quelque chose seulement à la porté des admins dans ce scénario.
C'est assurément flatteur de sécuriser sa bécane. Mais c'est trop compliqué et mieux vaut laisser ça à des spécialistes. Et dans ce cas, ces derniers ont besoin d'outils évolués afin qu'ils expriment toute leur compétence et non être limité par un outil ... limité/mal foutu.
J'utilise SeLinux. Désolé, c'est trop fort. Ma bécane a SeLinux et je m'en fous. Je ne m'occupe pas de la sécurité, d'autres le font (SeLinux). C'est ceci qu'il faut pour la grande majorité des gens. Pas d'un outil pour faire "magiquement" de la sécurité.
[^]Re: SMACK
Ce n'est pas la simplicité de AppArmor qui m'énerve, c'est sa façon simpliste, voire marketing, de faire de la sécurité. Par exemple l'auto-apprentissage est de la connerie. Il implique une mauvaise pratique de la sécurité. C'est séduisant, mais c'est de la connerie.
Dis moi mon cher, c'est quoi le probleme avec le mode d'auto-apprentissage de AppArmor ? C'est quoi la mauvaise pratique de securite la-dedans ?
Ce n'est pas car on a un système de protection, que pour mieux se protéger le premier venu doit le bidouiller. Comme pour le système de protection classique, ce qui est fournit doit être OK et on n'a pas à y toucher sauf cas exceptionnel. Il est OK car des experts ont bossé dessus. SeLinux c'est parail. SeLinux (avec ses règles) est fait pour marcher de suite et sans bidouiller (sauf cas très particulier).
Ca c'est sur, SELinux avec des regles minimales il n'y a pas besoin d'y toucher, il marche.
Le probleme c'est qu'il ne couvrira que les softs pour lesquels il a des regles, et si tu veux etendre la couverture, ben faut le configurer.
Et AppArmor c'est la meme chose, ce mode d'auto-apprentissage ne sert a rien d'autre que creer des profiles pour des softs qui n'en ont pas encore. Il y a un serveur contenant des profiles pour plein de softs, ce mode d'auto-apprentissage est la pour les softs qui n'en ont pas encore et sert a creer des profiles bien plus rapidement que si c'etait fait a la main uniquement.
T'as une certaine habitude a avoir des positions tres tranchees, et il me semble que regulierement tu n'es pas en position de defendre ces positions par autre chose que l'utilisation de mots tels que "magique".
Au hasard ton point de vue sur le modele de securite dans Windows, qui est pourtant absolument identique a celui dans Linux (a la difference pres qu'il y a des ACLs par defaut), mais que tu denigres constamment sans jamais pouvoir donner d'element technique.
[^]Re: SMACK
Au hasard ton point de vue sur le modele de securite dans Windows, qui est pourtant absolument identique a celui dans Linux (a la difference pres qu'il y a des ACLs par defaut),
et moi qui croyais que justement il y avait plusieurs modèles de sécu dans linux (smack, selinux, apparmor, ...)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: SMACK
> Au hasard ton point de vue sur le modele de securite dans Windows,
> qui est pourtant absolument identique a celui dans Linux
FAUX.
Le modèle UNIX a des variables d'environnement attachées aux processus et qui s'hérite de père en fils, mais non l'inverse. Un fils ne peut influencer le fils d'un autre processus. Cette indépendance est fondamentale pour la stabilité et la simplicité de l'ensemble et c'est pourquoi je déteste gconf. Lorsque je modifie un paramêtre important, je préfère relancer les applications. En plus, cela n'arrive pas souvent.
Sous Windows, les variables d'environnement sont globales par utilisateurs, voir pour le système. D'ailleurs, tout cela est stockée dans la base de registre qui est un énorme système de variable globale. C'est exactement ce que l'on déconseille à tout programmeur.
Sous UNIX, root avait (c'est en train de changer) tous les pouvoirs, ce n'est pas le cas sous Windows. Sous Windows, le root ne peut pas faire un chown...
Sous Windows, avec le système kerberos, on n'a pas de système équivalent a su, sudo... Bref de bit suid. Bilan, c'est une usine à gaz et une vrai daube lorsqu'on veut lancer en batch des choses sous un autre compte. Il suffit de voire le nombre de service qui tourne sous root sur un Windows pour voir l'échec de cette architecture de sécurité.
Je ne parle pas du compte SYSTEM qui existe sans exister et dont les scripts .bat ont un comportement parfois plus qu'étrange...
Alors oui, il y a des ACL sur les fichiers sous Windows et sous Linux. Ce n'est pas suffisant pour dire que la sécurité est basée sur le même modèle. Surtout qu'encore une fois, les ACL de Windows sont une telle usine à gaz qu'il y a tant de réglage possible que je n'ai pas encore rencontré une seule personne capable de faire des réglages beaucoup plus pointus que s'il y avait 4 ou 5 réglages possibles, comme sous UNIX ! La encore Windows à tuer les ACL avec leur complexité. D'ailleurs, lorsqu'on n'est pas en domaine, Microsoft a préféré les cacher aux utilisateurs, c'est tout dire.
[^]Re: SMACK
Le modèle UNIX a des variables d'environnement attachées aux processus et qui s'hérite de père en fils, mais non l'inverse. Un fils ne peut influencer le fils d'un autre processus. Cette indépendance est fondamentale pour la stabilité et la simplicité de l'ensemble et c'est pourquoi je déteste gconf. Lorsque je modifie un paramêtre important, je préfère relancer les applications. En plus, cela n'arrive pas souvent.
Sous Windows, les variables d'environnement sont globales par utilisateurs, voir pour le système. D'ailleurs, tout cela est stockée dans la base de registre qui est un énorme système de variable globale. C'est exactement ce que l'on déconseille à tout programmeur.
Tu as tout faux. http://msdn2.microsoft.com/en-us/library/ms682009.aspx
Altering the environment variables of a child process during process creation is the only way one process can directly change the environment variables of another process. A process can never directly change the environment variables of another process that is not a child of that process.
Sous UNIX, root avait (c'est en train de changer) tous les pouvoirs, ce n'est pas le cas sous Windows. Sous Windows, le root ne peut pas faire un chown...
Faux encore, cf. http://support.microsoft.com/kb/308421
Sous Windows, avec le système kerberos, on n'a pas de système équivalent a su, sudo... Bref de bit suid. Bilan, c'est une usine à gaz et une vrai daube lorsqu'on veut lancer en batch des choses sous un autre compte.
Equivalent de su : runas.exe
sudo il n'y a pas d'equivalent par defaut, mais ca existe separament
Et tu m'expliqueras le rapport entre su et des services tournant sous root...
Je ne parle pas du compte SYSTEM qui existe sans exister et dont les scripts .bat ont un comportement parfois plus qu'étrange...
Perso, et au vu de ta meconnaissance du systeme, je pencherai pour une autre explication.
Surtout qu'encore une fois, les ACL de Windows sont une telle usine à gaz qu'il y a tant de réglage possible que je n'ai pas encore rencontré une seule personne capable de faire des réglages beaucoup plus pointus que s'il y avait 4 ou 5 réglages possibles, comme sous UNIX ! La encore Windows à tuer les ACL avec leur complexité.
Que tu ne les comprennes pas ne veut pas dire que personne ne les comprend. Il suffit de comprendre que les ACE sont executees dans l'ordre et que l'evaluation stoppe a la premier entree qui match pour comprendre comment ca fonctionne ,ca n'a rien de sorcier.
D'ailleurs, lorsqu'on n'est pas en domaine, Microsoft a préféré les cacher aux utilisateurs, c'est tout dire.
Effectivement, ca en dit long sur la finition de Windows pour le desktop, car ta grand-mere (et la mienne) n'ont aucune idee de ce qu'est une permission.
Au passage, tu noteras que Windows XP Pro n'a pas cette configuration, c'est uniquement la version Home.
Bref, je te conseille de lire le bouquin "Windows Internals" ...
[^]Re: SMACK
Sur les variables d'environnements, certes les modèles se ressemblent mais non les usages. En pratique sous Windows, elles sont stockés dans la base de registre et comme on lance dans 99% des cas des binaires, on utilise ces variables comme des variables globales. Il est vrai cependant que depuis quelques années, c'est mieux et un peu moins le zouk. Il y a encore peu, un sacré paquet de programme allait rajouter leur chemin dans la variable PATH par exemple.
AU niveau des droits et de http://support.microsoft.com/kb/308421, c'est toi qui n'a pas compris à mon sens. En root, je peux faire sous UNIX
chown toto:titi un_fichier
Sous Windows, tu as le droit de t'approprier un fichier mais tu ne peux pas le rendre a son propriétaire. Windows a été conçu pour protéger les utilisateurs de l'administrateur. Ainsi, l'admin ne peut pas prendre un fichier que l'utilisateur ne veut pas qu'il prennne sans qu'il le sache (changement du propriétaire a sens unique).
Pour su, tu me sors runas ! Cela n'a rien à voir, vas faire un runas sous admin pour lancer un executable sous le compte toto ! Cela ne marche pas car tu n'as pas le ticket kerberos. Tu es obligé d'avoir le mot de passe de toto. Comment tu fait pour avoir des services qui tournerait sur un parc de 100 machine sous un compte toto sans que celui-ci n'ai le même mot de passe, tu déploie comment ?
Moi je dis que ne pas avoir de bit suid fait que c'est la merde. Bilan 99% des services tourne sous admin. On pourrait imaginer autre chose que le bit suid mais qui soit opérationnel simplement.
> Et tu m'expliqueras le rapport entre su et des services tournant
> sous root...
Regardes les script d'init sous une debian et tu verras... Je veux lancer par exemple un service flexlm sous le compte matlab pour un serveur de licence matlab. Je fait comment sous Windows ? Et bien, dans 99% des cas, il tournera sous root. Sous linux, il tournera sous un compte qui ne sers qu'a cela,
C'est pas que cela soit impossible à faire sous WIndows, c'est qu'en pratique, ce n'est pas fait car c'est une usine à gaz pour faire des choses simples.
> Perso, et au vu de ta meconnaissance du systeme, je pencherai
> pour une autre explication.
Je viens de tomber sur un bogue bien étrange avec pskill.exe ! Et des spécialistes Windows autour de moi n'y comprennent rien ! Le compte SYSTEM n'est pas un vrai compte car il n'a pas de ruche... C'est toi qui est mauvaise langue, il y a des choses parfois bizarre lorsqu'on lance des choses sous SYSTEM à cause de cela. Mais lancer des trucs sous SYSTEM est une des seules méthodes pour les lancer sans avoir à stocker le mot de passe dans le registre...
Au niveau des ACL, j'ai très bien compris comment cela marche et pour cause, je fait des ACL depuis des années sous UNIX. Je te dis que beaucoup de personnes sous Windows n'y comprennent rien, c'est différent. Le fait d'avoir mis une tripoté d'ACL fait qu'en pratique, c'est très peu utilisé. Il faut voir le nombre de logiciel qu'on installe et ou on est obligé d'aller bidouiller les ACL pour que cela marche pas lorsqu'on n'est pas admin.
Tu vas me dire, les logiciels sont mal fait. Je te dis oui et c'est mal fait car le système d'ACL est trop complexe et que, n'ayant pas de sudo et de su correct, les dévelppeurs sont tous admin de leur poste. Bilan, c'est mal dévleloppé et cela, depuis des années... heureusement, les choses de ce coté là aussi sont moins pire qu'il y a quelques années.
Enfin, sur la finition de XP, il n'y a pas d'onglet sécurité sur XP Pro ! Ce n'est que lorsque tu intègre XP pro en domaine que tout change et que tu te retrouves avec une interface comme 2000.
Donc pas d'ACL pour l'utilisateur lambda s'il n'est pas en domaine...
Pour tout cela, je continue de penser que le modèle de Microsoft est mal pensé car presque 10 ans après la sortie de 2000, c'est encore mal intégré par plein de développeur.
[^]Re: SMACK
Sous Windows, tu as le droit de t'approprier un fichier mais tu ne peux pas le rendre a son propriétaire. Windows a été conçu pour protéger les utilisateurs de l'administrateur. Ainsi, l'admin ne peut pas prendre un fichier que l'utilisateur ne veut pas qu'il prennne sans qu'il le sache (changement du propriétaire a sens unique).
Sisi tu peux : http://wwwthep.physik.uni-mainz.de/~frink/chown/readme.html
Pour su, tu me sors runas ! Cela n'a rien à voir, vas faire un runas sous admin pour lancer un executable sous le compte toto ! Cela ne marche pas car tu n'as pas le ticket kerberos. Tu es obligé d'avoir le mot de passe de toto. Comment tu fait pour avoir des services qui tournerait sur un parc de 100 machine sous un compte toto sans que celui-ci n'ai le même mot de passe, tu déploie comment ?
Ah, j'ai mal compris ce que tu demandais effectivement.
Ben tu crees un compte local sur chaque machine et tu generes le mot de passe de maniere aleatoire pour chaque machine, mot de passe que tu utilises quand tu specifies le compte sous lequel le service demarre. A faire une fois (assez simple a faire avec WMI) et c'est tout.
Sinon, il y a deja les comptes LocalService et NetworkService que tu peux utiliser, la moitie des services sous Windows tournent avec un de ces 2 comptes, pas avec LocalSystem.
Je viens de tomber sur un bogue bien étrange avec pskill.exe ! Et des spécialistes Windows autour de moi n'y comprennent rien ! Le compte SYSTEM n'est pas un vrai compte car il n'a pas de ruche... C'est toi qui est mauvaise langue, il y a des choses parfois bizarre lorsqu'on lance des choses sous SYSTEM à cause de cela. Mais lancer des trucs sous SYSTEM est une des seules méthodes pour les lancer sans avoir à stocker le mot de passe dans le registre...
C'est quoi une ruche ?
Sinon il y a les comptes LocalService et NetworkService qui sont fait pour ca hein.
Quand au mot de passe , il est encrypte et accessible uniquement au systeme(si t'es admin tu peux l'avoir, mais si t'es admin tu peux faire ce que tu veux donc pas grave), bref si tu arrives la le lire, c'est que t'es deja admin sur la machine, pas tres utile.
Sinon, c'est quoi le bug ?
Tu vas me dire, les logiciels sont mal fait. Je te dis oui et c'est mal fait car le système d'ACL est trop complexe et que, n'ayant pas de sudo et de su correct, les dévelppeurs sont tous admin de leur poste. Bilan, c'est mal dévleloppé et cela, depuis des années... heureusement, les choses de ce coté là aussi sont moins pire qu'il y a quelques années..
Desole mais sudo / su sont a peu pres inutiles pour le developpeur moyen, Visual Studio, un debuggeur, ... tournent sans probleme en user local, tu lances une console ou autre avec runas.exe, tu peux ensuite lancer tes softs en admin(ou autre) si necessaire, mais dans la plupart des cas(applis non-systeme) c'est totalement inutile car l'appli tourne en user local.
Le probleme c'est que bcp de gens, y compris developpeurs, sont passes directement de Win9x a la lignee NT et ont amenes leurs habitudes avec eux. MS 'est mis a casser leurs habitudes avec UAC sur Vista, car leurs softs continuent de tourner mais il y a des pop-ups (voulez-vous autoriser xyz), et resultat les utilisateurs se plaignent aux developpeurs qui doivent fixer leurs softs.
Enfin, sur la finition de XP, il n'y a pas d'onglet sécurité sur XP Pro ! Ce n'est que lorsque tu intègre XP pro en domaine que tout change et que tu te retrouves avec une interface comme 2000.
Nope, il y a un bouton qui te demande si tu veux les permissions ou pas. Ma machine a la maison n'est pas dans un domaine, et j'ai mon tab de permissions avec les ACLs dedans.
[^]Re: SMACK
> Sisi tu peux :
> http://wwwthep.physik.uni-mainz.de/~frink/chown/readme.html
Je ne connaissais pas. Très bien même si cela n'a aps l'air tout jeune. Enfin, c'est pas très Microsoft comme solution...
> C'est quoi une ruche ?
Un bout de la base de registre.
Mon bogue avec pskill, je fait un script .bat avec un
pskill.exe -t -accepteula thunderbird;exe
Juste avant d'installer ensuite la dernière version de celui-ci. Le script marche super en inetractif. Je le lance le script sous OCS avec la commande
START /B /I mon_script.bat
Et bien, cela ne marche pas. Le script ouvre une fenêtre au pskill et s'arrête dessus. J'ai essayer avec d'autre option de START et en mettant du START et du CMD devant pskill, mon script OCS ouvre toujours un fenêtre et se bloque dessus, soit au niveau de la commande pskill, soit à la fin de mon_script ! Je suis passé à la commande prcview (pv.exe) et la, cela marche.
Bref, je ne sais pas ce qui se passe avec pskill et le compte sous lequel tourne l'agent OCS.
Sinon, on niveau des comptes, effectivement tu peux créer des comptes avec des mots de passe par machine de manière automatique et un mot de passe de 200 caractères inviolable... ce que je vois en pratique, c'est que les développeurs ne le font pas.
Je n'ai pas dis que la sécurité n'était pas possible sous Windows, je dis que comme c'est une usine à gaz, les personnes l'utilisent mal (en plus Microsoft ne nous aide pas car les outils en ligne de commande de bas niveau ne sont pas livré avec les versions de base du système, ce qui ne leur couterait rien). Du coup, comme tu le dis toi même, tous les services tournent sous le même compte...
Effectivement, c'est une mauvaise tradition qu'on pris les développeurs et cela s'améliore avec le temps. Un développeur n'a pas besoin d'être admin du poste pour développer sauf s'il veut aller jusqu'au bout et faire l'empaquetage. Et a ce niveau là, pour tester, il doit être root donc il l'est en permanence. Tant qu'il n'y aura pas un équivalent de 'sudo' pour installer et supprimer un logiciel sous un compte normal, il y aura des soucis à ce niveau à mon sens.
Enfin, je sais bien que sur un XP pro qui n'est pas en domaine, on peux faire apparaître l'onglet sécurité (mais que celui-ci apparait tout seul si on rentre en domaine). Combien de personne ont trouvé cette option, comme de personne l'on activé ?
[^]Re: SMACK
>Mais il a installé une F9 pour sa femme avec SeLinux activé (et en mode enforcing) sans s'en rendre compte...
Sans s'en rendre compte, c'est vite dit: je me souviens d'un rapport d'erreur de Linus sur un problème d'affichage de vidéo qui était lié a une mauvaise interaction entre VLC et SELinux.
[^]Re: SMACK
> Une bécane sur 4 ayant smolt d'installé !
Zut, j'avais mal compris la remarque. Effectivement les stats de smolt ne conserne que Fedora (malheureusement). On peut le confirmer en regardant l'onglet "OS".
J'aurais dû le préciser.
[^]Re: SMACK
smolt était un outil Fedora (comme l'était PackageKit, Codeina, system-config-printer, etc ...), depuis sa conception, il est ouvert à toutes les distributions.
Actuellement, smolt supporte OpenSuSE, Debian, Ubuntu, Archlinux, Frugalware et normalement toute distribution utilisant HAL.
[^]Re: SMACK
Certes, mais même si les stats smolt sont pour toutes les distributions, force est de constater que Fedora y fait plus de 99,5 % des stats.
Je le regrette bien.
[^]Re: SMACK
J'aurais bien contribué a baisser la proportion de fedora mais pas moyen de trouver de doc sur l'installation de smolt. Non, franchement, yum ceci ou rpm celà ça ne sert pas à grand chose. C'est dommage de ne pas trouver cette information ni sur le wiki ni dans les sources.
[^]Re: SMACK
100% dakodak
Une fois son noyau recompilé avec SElinux en dur, plus besoin de lsm.
De plus, les outils graphiques de gestion de la configuration de Selinux permettent vraiment à tout le monde de """"s'amuser"""" simplement avec SElinux (je pense surtout aux types boleens, maitrisable par tous rapidement)