> Je te conseille de jeter un coup d'oeil à PackageKit.
Formidable. Mais où tu veux en venir ?
Ce n'est pas car il y a jugé mieux que l'existant est à chier ou vaut zéro pour l'ergonomie.
Il n'y a jamais de truc définitif, on finit toujours par trouver/inventer mieux.
> Et la plupart des critiques que je fais à Pirut ont été corrigés et bien plus encore ...
Quelles critiques ?
Des critiques sur la conséquence que Pirut veux rester simple ? Sur la fait que Pirut veut être orienté grosse fonctionnalité (groupe) et non paquet ? Sur le fait que Pirut ne veut pas avoir une interface chargée mais rester simple ?
Tu ne critiques pas Pirut, tu critiques ses objectifs.
Pirut ne te satisfait OK. Je suis d'autant mieux placer pour le comprendre que j'utilise quasiment jamais Pirut. Mais ta critique c'est comme critiquer gedit en disant qu'il n'a pas les fonctionnalité d'emacs. Gedit ne veut pas être emacs, n'est pas un concurrent d'emacs.
> (..) its design does address some issues with Fedora's current package manager, and the active upstream development is also a hopeful sign.
Ça ne parle pas de problème d'ergonomie.
Ça propose PackageKit en alternative et pas en remplaçant de Pirut.
M'enfin, ça remplacera peut-être Pirut à long terme. À priori j'ai rien contre.
> Si on prends la vue par groupe, tu as à gauche les groupes, à droite les paquets. Et ça ne fait pas fouilli.
Apparament c'est ça ton problème. Pirut n'affiche pas les paquets par défaut mais les groupes seulement.
Mais creuse la question de pourquoi Pirut ne fait pas l'affichage des paquets par défaut ?
Si je veux installer un serveur web, c'est :
- catégorie : Serveur
- groupe : Serveur web
Et pour les paquets il y en a plus de 40 !
Tu crois que c'est raisonnable de montrer ça par défaut à l'utilisateur ?
Je ne crois pas.
Autre point que tu sembles vouloir ignorer, c'est qu'aux groupes sont associés des paquets par défaut.
L'objectif est de faire l"installation de "Serveur: Serveur web" et pas de httpd, mod_perl, mod_ssl, grupal, etc...
Donc dans les cas classiques, on n'a qu'à passer quelques groupes en revue et non des milliers de paquets. Un groupe est une fonctionnalité et non une facilité pour classer des paquets (contrairement à group de rpm). Le nombre de paquet nécessaire pour avoir cette fonctionnalité est un problème d'implémentation qu'il est meilleur de cacher à l'utilisateur dans la majorité des cas. Ça a des limites, mais dans ça répond à 95 % des cas.
Pirut est dans cette esprit.
Tu n'aime pas ça, OK. Mais tu n'as pas montré que c'était un problème d'ergonomie.
> Yumex permet même d'économiser un clic dans la vue Groupe en affichant automatiquement les paquets.
Le fait que les paquets soient "masqués" dans Pirut, c'est fait exprès. Mais tu ne veux pas le comprendre...
> Personne ne parle d'intégrer Yumex à Anaconda.
Pourtant c'est bien toi qui dit que Pirut est à chier ?
Mais ça ne serait pas à chier dans anaconda.
Expliques ta contradiction.
> Si au début du développement de Pirut, c'était le cas, ce n'est plus vrai aujourd'hui
Avant le faire le post précédent, j'ai installé Yumex et fait le "tour du propriétaire". Yumex est plus compliqué, donne beaucoup d'infos à l'utilisateur.
NB : je ne dis pas que c'est mal, mais que ce n'est pas adapté à un nouvel utilisateur.
> L'utilisateur de base ne se fait pas chier à se balader dans les menus.
La belle excuse. On croirait un pro-KDE, pro-des_milliers_options_svp.
> Le problème n'est pas sa simplicité mais son ergonomie qui est à chier
Ton argument est dans le même registre que ceux qui disent que nautilus est à chier et pas ergonomique car bidule peut faire des trucs compliqués en deux cliques et affiche tout.
C'est à chier, les dev Fedora sont des cons, le débât est clos.
Et alors ?
Les "accros" de Fedora ne vont probablement pas utiliser Pirut. Pirut n'est pas fait pour eux. Et ces derniers savent installer yumex ou utiliser yum en ligne de commande.
> La première chose qu'on fait dans les IP, c'est justement d'installer Yumex.
À une époque c'était synaptic...
> * ergonomie inexistante
N'importe quoi, Pirut a été fait avec l'ergonomie en tête.
> c'est l'exemple parfait d'une IHM fait par un développeur.
N'importe quoi encore (et du grand n'importe quoi), les specs de l'interface de Pirut ont été faites bien avant la moindre ligne de code (ça a peut-être été fait autour de FC2).
> Des gros onglets tout moches
Les goûts et es couleurs...
> dans la vue par groupes, il faut cliquer sur paquets optionnels pour afficher les paquets.
C'est fait exprès c'est pour des raisons ergonomique. Au-lieu de présenter 5000 paquets, on présente quelques groupes. Si l'utilisateur veut un truc spécifique, il le trouve en un clique.
> Interface peu responsive
Dans quel cas ?
Le gros problème est qu'il devrait mettre une "horloge" en pointeur de souris lorsqu'il fait un truc long. C'est souvent fait, mais pas toujours.
> chaque clic sur Lister = réactualisation des données
Le problème est qu'il relis tout à chaque clique au-lieux de le garder en mémoire.
Ceci peut effectivement être considéré comme un bug. Pour moi, c'est un bug.
> mais avec une interface mieux pensée
Comment ça "mieux pensée" ?
Et dans quel cas d'utilisation ?
Prend un petit exemple. Je veux installer XFCE ou Postgresql. Combien de clique je dois faire avec Yumex ? Combien avec Pirut ?
Le parcours n'est-il pas plus évident avec Pirut ?
L'ergonomie de yumex est peut-être (voire probablement) excellente pour un utilisateur avisé ou un "bidouilleur". Mais pour un nouveau venu c'est très très discutable.
Yumex s'ouvre sur une vue console et affiche des messages incompréhensible (pour un nouveau venu).
Yumex n'envoie pas directement sur la vue groupe (la plus simple). Il faut deviner qu'il faut cliquer sur un icone sur la toolbar à gauche.
Avec Yumex on peut enregistrer des profiles. Des profiles de quoi ?
Il y a des préférences avec 4 onglets.
L'interface de Pirut est réutilisée à l'installation. Je ne crois pas que mettre l'interface de yumex dans anaconda va simplifier anaconda...
Pour un nouvel utilisateur, l'ergonomie de Pirut est selon moi indiscutablement meilleur que celle de Yumex. Ça n'enlève rien aux mérite de Yumex.
Moi j'utilise quasi que yum (ligne de commande). Mais ce n'est pas car j'utilise quasiment que yum et que Pirut ne fait pas mon bonheur, que je dois vonir sur Pirut ("ergonomie inexistante", etc).
Pirut a ses mérites, il faut les reconnaitre. Idem pour yum en ligne de commande ou Yumex.
Pirut ne veut pas être le gestionnaire ultime. C'est un gestionnaire volontairement simple.
> +1 , Pirut aurait du sauté depuis un moment en faveur de Yumex (bien plus abouti),
Je connais mal Yumex, mais je ne suis pas d'accord.
OK pour dire que Pirut n'est pas "full-feature" ou est insufisament souple ou verbeux.
Mais Pirut est le gestionnaire par défaut. Le gestionnaire qu'on va présenter à tout le monde y compris les plus neuneu.
> je suppose qu'on a pas voulu heurter Jeremy Katz.
> Il faut que tu précises : tu n'as pas chié une pendule, car c'était Fedora. S'il s'agissait d'une autre distribution, tu aurais trouvé ça scandaleux.
Car j'ai fait du bruit pour le bug Xorg d'Ubuntu ?
C'est juste un exemple.
Arrêtez avec vos fastames me voyant anti-tout sauf Fedora. Vous êtes dans le délire total.
Quand je n'aime pas une distribution, je ne l'argument jamais en disant qu'elle est bugguée ou car elle ne s'installe pas sur ma bécane ou car le driver bidule ne marche pas. Les bugs ça existent et pour toutes les distributions.
Tu prends un truc gratos et ça ne marche pas à cause d'un driver.
Une distribution qui se veut "blending edge".
Que dire ?
Ben c'est la vie.
La F8 que j'ai me fais des freezes de façon très très aléatoire. C'est pénible, c'est la vie. Je n'ai pas fait de rapport de bug car je ne suis pas foutu d'avoir le début d'une amorce de piste.
Avec mon ancienne F6, ma carte DVB n'a pas marché durant plusieurs mois car il y avait un bug (bug upstream dans le noyau 2.6.19). C'est la vie, je n'ai pas chié une pendule.
Par contre, si j'achète une RHEL et qu'une mise à jour (un "yum update" pas un passage de RHEL n à n+1) casse quelque chose, ben là je vais gueuler.
> Mon courroux
Change de distribution.
Je suis un supporter de Fedora. Si Fedora perd un utilisateur qui correspond à sa sible, ça m'emmerde un peu. Mais si l'utilisateur c'est trompé de distribution, ça ne m'emmerde aucunement.
Tu veux un truc qui marche tout le temps, sans bug, et si ça ne marche pas tu veux avoir le droit de casser la gueule au distributeur. Fedora n'est pas la distribution qu'il te faut.
> On peut enlever le noyau qui ne dépend que du moment ou tu sort ta distro. Si tu sort en octobre t'a un 2.6.22, si tu sort en novembre t'a un 2.6.23...etc etc
C'est juste une question de timing.
Oui et non. Concernant le timing, Ubuntu pouvait sortir en 2.6.23. Mais Ubuntu est resté à la version stable en cours durant le développement de la dernière Ubuntu. Ce n'est pas un reproche. Fedora durant le développement de F8 a utilisé un 2.6.23 en développement. F9 en préparation a un 2.6.24 (rc évidemment).
Pour RHEL, c'est toujours une "vieille" version du noyau par exemple. Donc ce n'est pas qu'une question de timing.
> Ensuite pour Pirut je crois que c'est le gestionnaire de paquets chez Fedora non ?
Ben oui. Donc ce n'est évidemment pas quelque chose qu'"on trouve sur les distributions du moment" contrairement à ce que dire frlinux.
> En revanche, le pré-compilé plante à coup sûr. Donc la faute à Fedora et pas au kernel
Pas forcément. Fedora a peut-être une configuration que ton driver ne supporte pas. Le problème est très très probablement du côté de ton driver. Virer des fonctionnalités du noyau pour faire plaisir à ton driver n'est pas la solution à long terme. La solution est de corriger le driver.
Tu préfères que pulseaudio soit disponible dans 10 ans ?
Ça t'indiffère que des distributions fassent de l'"investissement" en recherche/innovation au-lieu de seulement faire le job de base d'un distributeur ?
L'innovation ce n'est pas stérile.
> F8 est peut-être la plus innovante du moment, mais ce ne sera sans doute plus le cas dans qulques mois...
Oui. Mais ça c'est la nature du logiciel libre (pouvoir copier/adapter).
Mais l'innovation il faut bien que quelqu'un la fasse en premier.
Que tu préfères les innovations de Fedora dans Ubuntu, par exemple, personne ne va te le reprocher. Les goûts et les couleurs...
Mais un travail d'innovation (ou seulement d'intégration/test) a été fait dans Fedora, il faut le reconnaitre, et le reconnaitre comme bénéfique pour tout le monde. Ce n'est pas stérile.
> elle contient son lot de bonnes choses très proches de ce que l'on trouve sur les distributions du moment : noyau 2.6.23, KDE 3.5.8, Gnome 2.20, Xorg 7.3, compiz fusion, PulseAudio, IcedTea, pirut tout neuf et tout propre, XFCE 4.4.1, Online Desktop, CodecBuddy, OpenOffice.org 2.3.
A ma connaissance il n'y a que Fedora 8 qui propose :
- PulseAudio
- IcedTea
- Pirut
- Online Desktop
- noyau 2.6.23 (les autres ont un 2.6.22)
D'autres le propose peut-être mais ça doit être en testing ou équivalent.
J'ai utilisé ton source et j'ai (sous F8) : $ for i in `seq 1 10`; do ./test; done
Dans la pile: 0xbf81475c
Dans le tas: 0x8dcb008
Dans la pile: 0xbfef463c
Dans le tas: 0x8f4a008
Dans la pile: 0xbfa931dc
Dans le tas: 0x85b8008
Dans la pile: 0xbfeb59cc
Dans le tas: 0x83f6008
Dans la pile: 0xbf91785c
Dans le tas: 0x8141008
Dans la pile: 0xbfb6ea5c
Dans le tas: 0x8441008
Dans la pile: 0xbffa76ec
Dans le tas: 0x87b8008
Dans la pile: 0xbfc67bac
Dans le tas: 0x864c008
Dans la pile: 0xbfcd5c1c
Dans le tas: 0x9448008
Dans la pile: 0xbfa5b99c
Dans le tas: 0x898c008
> En gros, la plage de valeur possible n'est pas très étendue
Oui. Mais il faut une bonne centaine de tentative au moins. C'est toujours ça de pris. Et 99 fois sur 100 que le craker va faire une tentative, ça va être un segfault. Ça va donc probablement se remarquer.
> ASLR n'est pas très utile.
C'est un petit plus. Combiné avec NX (ou ExecShield), c'est un gros plus.
En passant, le bug dans selinux-policy-targeted pour bugzilla a été corrigé. C'est l'affaire de deux ou trois jours pour que ça arrive en mise à jours officiel.
Plus généralement.
On est ici, pour beaucoup, amoureux d'Unix/Linux. C'est astucieux et clean. On s'est bien pris la tête pour comprendre comme ça marche sous le capot et ça nous a été très profitable.
Notre "amour" fait qu'on pense Unix et qu'on est rétissant à d'autres solutions. Souvent à juste titre. Mais parfois on est rétissant à d'autres solutions car elles demandent de se remettrent en cause.
On ne le devrait pas toujours. Par exemple OLPC est un Linux, son modèle de sécurité est complètement différent d'un Unix (OLPC utilise aussi SeLinux :-)).
Il n'est pas question de dire que SeLinux est indispensable. Telque le conçois Fedora par exemple, un système doit rester sûr sans SeLinux (au moins autant que n'importe quel système sans SeLinux).
M'enfin, il est peut-être temps d'aller plus loins que le modèle Unix classique. Si on a un linux pour les masses, on ne va pas demander à tous les utilisateurs d'être un expert Unix ou d'avoir de bons fondamentaux en Unix. Si Linux devient le système le plus utilisé, il y aura plein programmes tous plus flashy les uns que les autres à downloader. Sous Windows ce sont souvent des spyware/etc et il faut un anti-virus. Si on veut répondre à ce problème qui se posera, il faut aller plus loins que le modèle Unix classique.
Bien des évolutions se sont faites avec des résistances. Bien des distributions on mis des mois (pour ne pas dire années) pour passer à UTF ou pam. De nombreux utilisateurs préféraient s'ajouter au groupe "sound" que de laisser pam_console s'occuper de ça (maintenant c'est ConsoleKit l'avenir (c'est dans déjà utilisé par F8)).
Rester cramponné à nos habitudes/traditions n'est pas toujours bon. D'autant plus que SeLinux ne diminue jamais la sécurité ! Il n'autorise jamais ce que Linux sans SeLInux refuserait.
Es-ce que l'avenir sera SeLinux ?
J'en sais rien. Mais j'ai du mal à croire que le modèle actuel Unix sera satisfaisant à l'avenir.
Pour le fun. J'ai Firefox qui a planté il y a 2 minutes. Il a déclenché SeLinux. Comme il y a audit et setroubleshooting, j'ai une applet qui clignote. Je clique, et j'ai un diagnostique (tout n'est pas traduit encore) :
Résumé
SELinux empêche /usr/lib/firefox-2.0.0.9/firefox-bin de changer un segment de mémoire inscriptible en segment exécutable.
Description détaillée
The /usr/lib/firefox-2.0.0.9/firefox-bin application attempted to change the access protection of memory (e.g., allocated using malloc). This is a potential security problem. Applications should not be doing this. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests web page [ http://people.redhat.com/drepper/selinux-mem.html ] explains how to remove this requirement. If /usr/lib/firefox-2.0.0.9/firefox-bin does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed. Please file a bug report [ https://bugzilla.redhat.com/enter_bug.cgi ] against this package.
Autoriser l'accès
If you trust /usr/lib/firefox-2.0.0.9/firefox-bin to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t /usr/lib/firefox-2.0.0.9/firefox-bin". You must also change the default file context files on the system in order to preserve them even on a full relabel. "semanage fcontext -a -t unconfined_execmem_exec_t /usr/lib/firefox-2.0.0.9/firefox-bin"
La commande suivante autorisera cet accès :chcon -t unconfined_execmem_exec_t /usr/lib/firefox-2.0.0.9/firefox-bin
Il faudrait que l'utilisateur puisse modifier des règles pour les programme qu'il lance lui-même sans passer par root (l'utilisateur à toujours le droit de faire des connerie si il insiste). C'est prévu à moyen terme par SeLinux.
Si tu veux dire qu'en général il vaut mieux un truc personnalisé aux petits oignons (s'il est effectivement bien fait) qu'un truc généraliste, ben oui.
> S'il s'agit du desktop, où l'ensemble des logiciels fournis par le distributeur suffisent généralement à l'utilisateur, tout à fait (et pour les logiciels non fournis par la distribution, donc sans règles SELinux, on sera tolérant en considérant que les desktop est généralement moins critique que les serveur).
SeLinux débute pour le desktop. Mais les possibilités sont énormes. Par exemple si un utilisateur lance un programme dans son $HOME, on peut faire que ce programme (qui a été downloadé sur un signe warez) ne puisse lire .thunderbird, etc...
A l'avenir (car SeLinux débute dans le domaine du desktop), les paquets rpm/deb qui sont installés et ne sont pas signés par une source de confiance pourront avoir des privilèges limités (interditions de lire/écrire/supprimer des fichiers que le programme n'a pas créé, etc). Notons qu'un "bête" rpm est un problème puisqu'il s'installe avec les droits root. [admin@one rsync]$ rpm -q --scripts firefox
postinstall scriptlet (using /bin/sh):
update-desktop-database /usr/share/applications
preuninstall scriptlet (using /bin/sh):
# is it a final removal?
if [ $1 -eq 0 ]; then /bin/rm -rf /usr/lib/firefox-2.0.0.9/components /bin/rm -rf /usr/lib/firefox-2.0.0.9/extensions
fi
postuninstall scriptlet (using /bin/sh):
update-desktop-database /usr/share/applications
Le "rm -rf" pourrait être un "rm -rf /", il marcherait très bien.
Donc dans les scripts d'installation tu peux faire tout et n'importe quoi et sous le compte root. Avec SeLinux tu peux gérer ce type de problème. Problème qui se posera à l'avenir.
> Ainsi les applications critiques exposés au réseau ne seront finement protégés qu'à condition que l'admin écrive ou affine lui-même ses règles SELinux.
Le httpd de Fedora avec SeLinux n'a pas le droit de lire /etc (sauf /etc/httpd et quelques bricoles) ni les fichiers dans /tmp (sauf ceux créés par apache).
Il y a plein de "petites choses" dans ce gout. Et tu as ça par défaut !
Tu as ça aussi si l'administrateur à fait des conneries (par exemple un malheureux chmod -R 777 /etc). Si un utilisateur à fait chmod -R 777 ~, ben apache (ou un script d'apache) ne pourra pas y lire.
Si tu utilises mod_user (avec ou sans suexec) d'apache ça veut alors dire que $HOME/public_html est accessible. Et donc $HOME. Et donc tous les fichiers à l'intérieur dès que l'utilisateur fait un oubli. SeLinux gère ça. apache ne peut lire et écrire que dans $HOME/public_html quelque soit les conneries de l'utilisateur.
Il y a des tonnes de serveur prétendument "finenement protégé" qui ne sont pas au niveau de ce qui est fait par SeLinux sous Fedora par défaut. Par défaut sans que tu te prennes la tête. Et l'expertise que tu as n'est pas d'un administrateur qui a fait ça à l'arrache car il est sous pression, mais par des experts.
> Et là, la complexité est un handicap
La complexité est toujours un handicap/problème. Mais es-ce Selinux qui est complexe ou la sécurité qui est complexe ?
Avec chroot, les droits DAC, aussi ACL, des programmes bien sélectionnés et audités, etc et un admistrateur compétent tu peux avoir un système très sûr. Aucun doute sur ça. Pour ces cas on n'a pratiquement pas besoin de SeLinux. Ces cas sont finalement très limité.
Par contre dans pleins pleins d'autre cas, SeLinux est un atout. Ce n'est pas un atout qui ajoute forcément de la compléxité. J'ai installé bugzilla et awstats, il y a déjà des règles SeLinux, j'ai rien à faire. Plus simple que ça tu meurs.
Pour les cas spécifiques ?
Ben il y aura du boulot. Oui. Mais au lieux de te prendre la tête pour mod_user, pour bugzilla, pour awstats, etc, ben tu ne te prends la tête que pour les choses très spécifiques.
Il y a une communauté SeLinux très dynamique, tu trouveras de l'aide sans problème. SeLinux est aussi l'outil qui répond à une très vaste palette de problème (bien au-delà de ce que proposer le modèle DAC, ACL, chroot, etc). Donc au-lieu de te demander qu'elle solution il te faut dans les 10 000 addons sécurité, il te suffit de connaitre SeLinux. Ça simplifie grandement. Donc la complexité de SeLinux est très relative. D'autant plus qu'on a de plus en plus d'outil de haut niveau pour faire ses propres règles ou pour faire un audit rigoureux des règles (atout énorme de SeLinux).
SeLinux te permet aussi d'exprimer ton besoin (domaine, object, attribut, etc) et celà aussi ça simplifie la vie lorsque la situation est complexe.
> se montre odieux et borné comme seuls les dévs sécu noyau savent l'être (à la hauteur des devs SELinux ou de Theo de Raadt), ...).
Les devs SeLinux sont "odieux" envers les fausses solutions (type AppArmor). Ils ne sont pas odieux vis-à-vis de ce qui est techniquement bien conçu (par exemple smack).
Et s'ils étaient aussi odieux que tu le dis, aussi odieux que Theo par exemple, SeLinux ne serait pas upstream.
> les développeurs noyaux semblent considérer que perdre 5% en vitesse est inacceptable même si la sécurité du noyau s'en trouve nettement renforcée.
Oui. Mais Selinux ce n'est pas 5 % de perte en performance (ni 7 % comme le dit (ou l'a dit) Novell).
Dans quelques scénarios très spécifiques on peut monter à 3 % (cas où on accède à 10 000 fichiers différents par seconde et où SeLinux doit contrôler chaque accès). Généralement on ne remarque rien de rien. Il y a eu un bench entre Ubuntu et Fedora pour les jeux. La différence : 0,00000.
> Si on était amené à faire un sondage auprès des utilisateurs linux, je pense que l'on serait surpris de voir un grand pourcentage de personnes travaillant avec le noyau "basique" proposé par leur distribution favorite,
Inversement, beaucoup utilise le noyau/glibc "full feature" au niveau sécurité livré par la distribution sans s'en préoccuper. C'est le cas de Fedora par exemple.
> Il faut rajouter à ça qu'une simple activation de SELinux ne suffit pas.
Ça dépend comme est intégré SeLinux. Un noyau SeLinux sans règle de sécurité SeLinux est sans intérêt.
> Il faut chercher à comprendre ce que propose ce mécanisme et comment le configurer correctement
Ça dépend. Pour Fedora, dans la majorité des cas tu ne te soucis pas de ça et c'est déjà configuré. D'autres (des spécialistes) configurent Selinux pour toi comme les permissions de fichier sont déjà configurées dans toutes les distributions par exemple.
> ce qui n'est ni à la portée de tous
Effectivement.
> Ainsi, on risquerait fort de donner une fausse impression de sécurité en posant une configuration "générique" de SELinux par défaut, ce qui est encore plus dangereux que ne rien mettre du tout à mon avis.
Remarque très pertinente.
La sécurité ne se résume à un bouton sur on ou off.
Mais je te conseille, si tu as le temps, de regarder Fedora. SeLinux y est intégré et le travail ne c'est pas limité à configurer une option du noyau.
> S'il est suffisament compétent pour activer et paramétrer SELinux, il le fera de lui-même, et bien mieux que toute configuration préfabriquée.
J'en doute.
SeLinux (ses règles de sécurité) est un travail énorme (des années). Je ne crois pas d'un administrateur s'improvise expert Selinux du jours au lendemain.
> Mais je parlais dans le sens général d'une installation par défaut d'un utilisateur standard.
Peut-être que je t'ai mal compris. Mais tous les trucs précédents sont activés par défaut (même SeLinux (dans un mode qui est presque strict)). Donc tu installes une Fedora ou une RHEL (ou CentOS, etc), et voilà.
C'est un démaine où Fedora est en pointe : http://fedoraproject.org/wiki/Security/Features
Et tu as raison de le dire, il ne sagit uniquement d'appliquer quelques patch pour dire "on a ça", mais il faut que ça soit activé et utilisable dans la majorité des configurations. C'est le cas.
C'est un énorme travail. En passant, F8 a la fonctionnalité "compte visiteur" par défaut (grace à SeLinux) : http://danwalsh.livejournal.com/13376.html
C'est un bon début.
> Mais trouvez vous normal d'être obligé de patcher votre noyau pour renforcer la securité...
SeLinux est en standard.
> Pourquoi ce qui s'applique aux BSD ne fait figure que d'option sous Linux ?
Linux n'est qu'un noyau.
Certaine distribution renforce la sécurité.
Pour exemple pour Fedora/RH. il y a tout un tas de truc auquel je ne comprend pas grand chose et qui est parfois upstream :
* Default requires signed updates
* NX emulation using segment limits by default
* Support for Position Independent Executables (PIE)
* ASLR for Stack/mmap by default
* ASLR for vDSO (if vDSO enabled)
* Restricted access to kernel memory by default
* NX by default for supported processors/kernels
* Support for SELinux
* SELinux default enabled with targetted policies
* glibc heap/memory checks by default
* Support for FORTIFY_SOURCE, used on selected packages
* All packages compiled using FORTIFY_SOURCE
* Support for ELF Data Hardening
* All packages compiled with stack smashing protection
* Pointer encryption
Vous trouverez des pointeurs vers plus d'info ici : http://www.awe.com/mark/blog/200701041544.html
En passant, car ce n'est pas indiqué dans cette liste, les noyaux Fedora/RH on un contrôle de signature (gpg) lors du chargement des modules. Présent dans Fedora mais peu (voire pas) utilisé pour Fedora.
> C'est l'argument des devs de Grsecurity, pas le mien. Ne pas confondre le messager et la source.
Tu bosses à la poste ou c'est toi qui a choisi la source ?
> Manque de bol ce n'est pas Alan qui décide mais Linus.
Pourquoi manque de bol ?
Linus n'est pas là par hazard.
Le travail fournit par SeLinux est titanesque. L'éventualité que Linus soit d'accord pour virer LSM plane depuis 2005 je crois. Si Novell passe à SeLinux (ce que je crois), on n'aura une belle proportion de codeur Linux qui bosse pour une boite qui veut SeLinux. Si Linux accèpte AppArmor ou smack ou autre, il y aura de l'électricité dans l'air. Je crois que va dépasser l'incident diplomatique. J'ai du mal à imaginer ce qui va se passer.
> que tout le monde ne semble pas avoir le même avis que les devs de SeLinux.
Surtout les concurrents de SeLinux. J'y revient, mais "tout le monde" c'est qui ?
Que OOXML arrive a avoir un nombre respectable de vote à l'ISO, n'implique pas que je dois penser qu'OOXML est du bon matos et que finalement il lui faut la certification ISO comme ODF a la certification ISO.
Il y a qui et avec quel argument.
Les pro-OOXML peuvent être nombreux, pour moi ça ne change rien car les arguments (OOXML) sont nazes.
Les choix du noyaux doivent être principalement être motivé par les mérites techniques et non car telle ou telle solution est populaire. On est pas sur TF1.
Le seule reproche de SeLinux est la complixité. C'est compliqué mais ce que fait SeLinux est compliqué. C'est comme reprocher au code de gcc d'être compliquer. gcc est compliqué car ce qu'il fait est compliqué (optimisation, multi-language, cross-compilation, etc).
Ce n'est pas car je peux éditer à la main les règles de SeLinux que je dois savoir le faire pour profiter de SeLinux.
Comme ce n'est pas parceque j'ai les sources de Linux que je me sens obligé de bidouiller Linux lorsque je veux une fonctionnalité.
Lorsqu'on veut changer un paramètre de Linux (par exemple sa table de routage), je ne code pas des appels systèmes, je ne code pas des appels de fonction à la libc, je ne fais pas des scripts shell qui appellent ifconfig et route, j'utilise des outils de plus haut niveau (rc.* qui fait ça automatiquement, ou NetworkManager, etc). Sûr qu'aujourd'hui au moins 90 % des utilisateurs ne save pas utiliser ifconfig et route et encore moins coder des appels systèmes.
Ce qui est fait pour linux afin d'éditer les tables de routage peut-être fait pour SeLinux pour éditer les règles. Ça me semble évident à comprendre.
Que l'utilisateur final/lambda trouve aujourd'hui SeLinux compliqué a utiliser est logique. Je trouve ça compliqué aussi. C'est logique car le développement d'applis "user-friendly" commence à peine. Car l'architecture des règles commence à peine à être figée, etc. Mais les critiquef de complexité de Selinux venant de développeurs Linux frise le ridicule. Je ne vais pas voter contre iptables car je trouve /sbin/iptables imbitable et que ça fait des choses salement compliquée. Je ne vais pas voter pour iptables car system-config-firewall est simple d'utilisation. Si je suis développeur noyau je vais voter en fonction des fonctionnalités/performances que fournit iptables. Iptables fournit plein de fonctionnalité, il peut faire du compliqué et du simple, je vote pour. SeLinux fournit plein de fonctionnalité, il peut faire du compliqué et du simple, je vote pour. Mais certains dev Linux se mélange les crayons actuellement.
> que tout le monde ne semble pas avoir le même avis que les devs de SeLinux.
S'il y a un vote des codeurs de Linux pour choisir une infrastructure pour la sécurité, SeLinux arrivera probablement en tête. Et pas car les dev de SeLinux seraient majoritaire :-)
Si tu prends AppArmor, il est sévèrement critiqué par les dev Linux. Il reste le nouveau smack. Mais smack se veut simple et que simple. Il ne couvrira qu'un spectre des besoins en sécurité.
> En tout cas cette polémique va forcer Morris et les autres a travailler comme des fous sur l'amélioration de la simplicité d'utilisation de SeLinux car c'est ça qui est perçu comme étant sa grande faiblesse. Ce sera bénéfique pour tous !
Les pauvres. Après tout le boulot et le géni qu'ils ont fournit (gigantesque) on estime qu'ils méritent encore un coup de pied dans cul :-)
> Pourquoi Fedora a une si grande communauté de contributeur ?
Ce n'est pas tout à fait ce que je voulais dire. Fedora a peut-être moins de contributeur qu'Ubuntu ou Debian. Mais son niveau globale est assez élevé. C'est mon sentiment.
> Dans le cas d'un poste de travail, si c'est une machine pour faire du développement utilisée par un utilisateur non root, SELinux gère cela comment ?
Tu veux s'avoir ce que t'apporte SeLinux ?
Clairement dans ce contexte c'est moins intéressant que pour une serveur critique.
> En général, ce que l'on veut pour un poste de travail, c'est vérifier le comportement des applications clientes (à cause des chevaux de troie), comment cela est compatible avec la possibilité de développer ?
SeLinux ce n'est pas que l'id de l'utilisateur. C'est l'id ET d'autres informations. Par exemple es-ce que le processus est un fils de /sbin/login, si c'est via ssh, qu'elle est l'adresse ip, etc. Dont tu peux par exemple avoir des privilèges différents si t'es connecté à la console ou via ssh.
Si ta bécane est attaquée et que le cracker obtient le compte root, il ne peut rien faire si par exemple le compte root n'a pas été obtenu via /sbin/login. Ceci dépend évidemment de la configuration SeLinux. SeLinux c'est une infrastructure, ce n'est pas une politique de sécurité. SeLinux supporte plein de politique de sécurité.
SeLinux fait aussi la distinction entre initialisation de la bécane (configuration des péiphériques, etc) et le moment où est elle est fonctionnelle. Lorsque le boot est terminé, certaines actions ne sont plus possibles.
> Les distributions activant SELinux utilisent quel type de politique de sécurité dans ce cas d'une machine pour développeur ?
Fedora il n'y a pas de distinction (RHEL 5 propose les règles stricts qui ne sont pas adaptées à un poste desktop, mais ses règles vont être abandonnées). Que ce soit un serveur où un desktop c'est grosso-modo la même configuration. Les utilisateurs sont confinés (NB: c'est un domaine où débute SeLinux qui jusqu'à maintenant c'est principalement concentrés sur la partie serveur).
Pour Fedora (ça sera la même chose pour RHEL6) il n'y a deux types de configuration :
- targeted
- mls
targeted (qui devient de plus en plus strict) convient pour les cas classiques (aussi bien desktop que serveur). targeted supporte support les modèles MAC et RBAC. Mls est pour Multi Level Security. C'est pour l'armée, etc... : http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/(...)
MLS est aussi utilisable en poste desktop.
[^] # Re: Je m'inquiète.
Posté par IsNotGood . En réponse au journal KDE Rc1 is out. Évalué à 2.
- FREEZE !
- FREEZE !
- FREEZE !
KDE 4 a pris un retard délirant et il n'y a que depuis quelques mois que les mainteneurs font le forcing.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à 1.
Formidable. Mais où tu veux en venir ?
Ce n'est pas car il y a jugé mieux que l'existant est à chier ou vaut zéro pour l'ergonomie.
Il n'y a jamais de truc définitif, on finit toujours par trouver/inventer mieux.
> Et la plupart des critiques que je fais à Pirut ont été corrigés et bien plus encore ...
Quelles critiques ?
Des critiques sur la conséquence que Pirut veux rester simple ? Sur la fait que Pirut veut être orienté grosse fonctionnalité (groupe) et non paquet ? Sur le fait que Pirut ne veut pas avoir une interface chargée mais rester simple ?
Tu ne critiques pas Pirut, tu critiques ses objectifs.
Pirut ne te satisfait OK. Je suis d'autant mieux placer pour le comprendre que j'utilise quasiment jamais Pirut. Mais ta critique c'est comme critiquer gedit en disant qu'il n'a pas les fonctionnalité d'emacs. Gedit ne veut pas être emacs, n'est pas un concurrent d'emacs.
> (..) its design does address some issues with Fedora's current package manager, and the active upstream development is also a hopeful sign.
Ça ne parle pas de problème d'ergonomie.
Ça propose PackageKit en alternative et pas en remplaçant de Pirut.
M'enfin, ça remplacera peut-être Pirut à long terme. À priori j'ai rien contre.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à 0.
Apparament c'est ça ton problème. Pirut n'affiche pas les paquets par défaut mais les groupes seulement.
Mais creuse la question de pourquoi Pirut ne fait pas l'affichage des paquets par défaut ?
Si je veux installer un serveur web, c'est :
- catégorie : Serveur
- groupe : Serveur web
Et pour les paquets il y en a plus de 40 !
Tu crois que c'est raisonnable de montrer ça par défaut à l'utilisateur ?
Je ne crois pas.
Autre point que tu sembles vouloir ignorer, c'est qu'aux groupes sont associés des paquets par défaut.
L'objectif est de faire l"installation de "Serveur: Serveur web" et pas de httpd, mod_perl, mod_ssl, grupal, etc...
Donc dans les cas classiques, on n'a qu'à passer quelques groupes en revue et non des milliers de paquets. Un groupe est une fonctionnalité et non une facilité pour classer des paquets (contrairement à group de rpm). Le nombre de paquet nécessaire pour avoir cette fonctionnalité est un problème d'implémentation qu'il est meilleur de cacher à l'utilisateur dans la majorité des cas. Ça a des limites, mais dans ça répond à 95 % des cas.
Pirut est dans cette esprit.
Tu n'aime pas ça, OK. Mais tu n'as pas montré que c'était un problème d'ergonomie.
> Yumex permet même d'économiser un clic dans la vue Groupe en affichant automatiquement les paquets.
Le fait que les paquets soient "masqués" dans Pirut, c'est fait exprès. Mais tu ne veux pas le comprendre...
> Personne ne parle d'intégrer Yumex à Anaconda.
Pourtant c'est bien toi qui dit que Pirut est à chier ?
Mais ça ne serait pas à chier dans anaconda.
Expliques ta contradiction.
> Si au début du développement de Pirut, c'était le cas, ce n'est plus vrai aujourd'hui
Avant le faire le post précédent, j'ai installé Yumex et fait le "tour du propriétaire". Yumex est plus compliqué, donne beaucoup d'infos à l'utilisateur.
NB : je ne dis pas que c'est mal, mais que ce n'est pas adapté à un nouvel utilisateur.
> L'utilisateur de base ne se fait pas chier à se balader dans les menus.
La belle excuse. On croirait un pro-KDE, pro-des_milliers_options_svp.
> Le problème n'est pas sa simplicité mais son ergonomie qui est à chier
Ton argument est dans le même registre que ceux qui disent que nautilus est à chier et pas ergonomique car bidule peut faire des trucs compliqués en deux cliques et affiche tout.
C'est à chier, les dev Fedora sont des cons, le débât est clos.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à 1.
Et alors ?
Les "accros" de Fedora ne vont probablement pas utiliser Pirut. Pirut n'est pas fait pour eux. Et ces derniers savent installer yumex ou utiliser yum en ligne de commande.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à 1.
À une époque c'était synaptic...
> * ergonomie inexistante
N'importe quoi, Pirut a été fait avec l'ergonomie en tête.
> c'est l'exemple parfait d'une IHM fait par un développeur.
N'importe quoi encore (et du grand n'importe quoi), les specs de l'interface de Pirut ont été faites bien avant la moindre ligne de code (ça a peut-être été fait autour de FC2).
> Des gros onglets tout moches
Les goûts et es couleurs...
> dans la vue par groupes, il faut cliquer sur paquets optionnels pour afficher les paquets.
C'est fait exprès c'est pour des raisons ergonomique. Au-lieu de présenter 5000 paquets, on présente quelques groupes. Si l'utilisateur veut un truc spécifique, il le trouve en un clique.
> Interface peu responsive
Dans quel cas ?
Le gros problème est qu'il devrait mettre une "horloge" en pointeur de souris lorsqu'il fait un truc long. C'est souvent fait, mais pas toujours.
> chaque clic sur Lister = réactualisation des données
Le problème est qu'il relis tout à chaque clique au-lieux de le garder en mémoire.
Ceci peut effectivement être considéré comme un bug. Pour moi, c'est un bug.
> mais avec une interface mieux pensée
Comment ça "mieux pensée" ?
Et dans quel cas d'utilisation ?
Prend un petit exemple. Je veux installer XFCE ou Postgresql. Combien de clique je dois faire avec Yumex ? Combien avec Pirut ?
Le parcours n'est-il pas plus évident avec Pirut ?
L'ergonomie de yumex est peut-être (voire probablement) excellente pour un utilisateur avisé ou un "bidouilleur". Mais pour un nouveau venu c'est très très discutable.
Yumex s'ouvre sur une vue console et affiche des messages incompréhensible (pour un nouveau venu).
Yumex n'envoie pas directement sur la vue groupe (la plus simple). Il faut deviner qu'il faut cliquer sur un icone sur la toolbar à gauche.
Avec Yumex on peut enregistrer des profiles. Des profiles de quoi ?
Il y a des préférences avec 4 onglets.
L'interface de Pirut est réutilisée à l'installation. Je ne crois pas que mettre l'interface de yumex dans anaconda va simplifier anaconda...
Pour un nouvel utilisateur, l'ergonomie de Pirut est selon moi indiscutablement meilleur que celle de Yumex. Ça n'enlève rien aux mérite de Yumex.
Moi j'utilise quasi que yum (ligne de commande). Mais ce n'est pas car j'utilise quasiment que yum et que Pirut ne fait pas mon bonheur, que je dois vonir sur Pirut ("ergonomie inexistante", etc).
Pirut a ses mérites, il faut les reconnaitre. Idem pour yum en ligne de commande ou Yumex.
Pirut ne veut pas être le gestionnaire ultime. C'est un gestionnaire volontairement simple.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à 1.
Je connais mal Yumex, mais je ne suis pas d'accord.
OK pour dire que Pirut n'est pas "full-feature" ou est insufisament souple ou verbeux.
Mais Pirut est le gestionnaire par défaut. Le gestionnaire qu'on va présenter à tout le monde y compris les plus neuneu.
> je suppose qu'on a pas voulu heurter Jeremy Katz.
Ajoute moi à la liste dans ce cas.
[^] # Re: Quelques "petits" problèmes...
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à 1.
Car j'ai fait du bruit pour le bug Xorg d'Ubuntu ?
C'est juste un exemple.
Arrêtez avec vos fastames me voyant anti-tout sauf Fedora. Vous êtes dans le délire total.
Quand je n'aime pas une distribution, je ne l'argument jamais en disant qu'elle est bugguée ou car elle ne s'installe pas sur ma bécane ou car le driver bidule ne marche pas. Les bugs ça existent et pour toutes les distributions.
[^] # Re: Quelques "petits" problèmes...
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à -4.
Tu prends un truc gratos et ça ne marche pas à cause d'un driver.
Une distribution qui se veut "blending edge".
Que dire ?
Ben c'est la vie.
La F8 que j'ai me fais des freezes de façon très très aléatoire. C'est pénible, c'est la vie. Je n'ai pas fait de rapport de bug car je ne suis pas foutu d'avoir le début d'une amorce de piste.
Avec mon ancienne F6, ma carte DVB n'a pas marché durant plusieurs mois car il y avait un bug (bug upstream dans le noyau 2.6.19). C'est la vie, je n'ai pas chié une pendule.
Par contre, si j'achète une RHEL et qu'une mise à jour (un "yum update" pas un passage de RHEL n à n+1) casse quelque chose, ben là je vais gueuler.
> Mon courroux
Change de distribution.
Je suis un supporter de Fedora. Si Fedora perd un utilisateur qui correspond à sa sible, ça m'emmerde un peu. Mais si l'utilisateur c'est trompé de distribution, ça ne m'emmerde aucunement.
Tu veux un truc qui marche tout le temps, sans bug, et si ça ne marche pas tu veux avoir le droit de casser la gueule au distributeur. Fedora n'est pas la distribution qu'il te faut.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à 1.
C'est juste une question de timing.
Oui et non. Concernant le timing, Ubuntu pouvait sortir en 2.6.23. Mais Ubuntu est resté à la version stable en cours durant le développement de la dernière Ubuntu. Ce n'est pas un reproche. Fedora durant le développement de F8 a utilisé un 2.6.23 en développement. F9 en préparation a un 2.6.24 (rc évidemment).
Pour RHEL, c'est toujours une "vieille" version du noyau par exemple. Donc ce n'est pas qu'une question de timing.
> Ensuite pour Pirut je crois que c'est le gestionnaire de paquets chez Fedora non ?
Ben oui. Donc ce n'est évidemment pas quelque chose qu'"on trouve sur les distributions du moment" contrairement à ce que dire frlinux.
[^] # Re: Quelques "petits" problèmes...
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à 4.
Pas forcément. Fedora a peut-être une configuration que ton driver ne supporte pas. Le problème est très très probablement du côté de ton driver. Virer des fonctionnalités du noyau pour faire plaisir à ton driver n'est pas la solution à long terme. La solution est de corriger le driver.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à 6.
Tu préfères que pulseaudio soit disponible dans 10 ans ?
Ça t'indiffère que des distributions fassent de l'"investissement" en recherche/innovation au-lieu de seulement faire le job de base d'un distributeur ?
L'innovation ce n'est pas stérile.
> F8 est peut-être la plus innovante du moment, mais ce ne sera sans doute plus le cas dans qulques mois...
Oui. Mais ça c'est la nature du logiciel libre (pouvoir copier/adapter).
Mais l'innovation il faut bien que quelqu'un la fasse en premier.
Que tu préfères les innovations de Fedora dans Ubuntu, par exemple, personne ne va te le reprocher. Les goûts et les couleurs...
Mais un travail d'innovation (ou seulement d'intégration/test) a été fait dans Fedora, il faut le reconnaitre, et le reconnaitre comme bénéfique pour tout le monde. Ce n'est pas stérile.
# Re:
Posté par IsNotGood . En réponse au journal Test de la Fedora 8. Évalué à 4.
A ma connaissance il n'y a que Fedora 8 qui propose :
- PulseAudio
- IcedTea
- Pirut
- Online Desktop
- noyau 2.6.23 (les autres ont un 2.6.22)
D'autres le propose peut-être mais ça doit être en testing ou équivalent.
[^] # Re: L'ASLR ne sert à rien
Posté par IsNotGood . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 1.
J'ai utilisé ton source et j'ai (sous F8) :
$ for i in `seq 1 10`; do ./test; done
Dans la pile: 0xbf81475c
Dans le tas: 0x8dcb008
Dans la pile: 0xbfef463c
Dans le tas: 0x8f4a008
Dans la pile: 0xbfa931dc
Dans le tas: 0x85b8008
Dans la pile: 0xbfeb59cc
Dans le tas: 0x83f6008
Dans la pile: 0xbf91785c
Dans le tas: 0x8141008
Dans la pile: 0xbfb6ea5c
Dans le tas: 0x8441008
Dans la pile: 0xbffa76ec
Dans le tas: 0x87b8008
Dans la pile: 0xbfc67bac
Dans le tas: 0x864c008
Dans la pile: 0xbfcd5c1c
Dans le tas: 0x9448008
Dans la pile: 0xbfa5b99c
Dans le tas: 0x898c008
> En gros, la plage de valeur possible n'est pas très étendue
Oui. Mais il faut une bonne centaine de tentative au moins. C'est toujours ça de pris. Et 99 fois sur 100 que le craker va faire une tentative, ça va être un segfault. Ça va donc probablement se remarquer.
> ASLR n'est pas très utile.
C'est un petit plus. Combiné avec NX (ou ExecShield), c'est un gros plus.
[^] # Re: Pourquoi une option ?
Posté par IsNotGood . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 1.
En passant, le bug dans selinux-policy-targeted pour bugzilla a été corrigé. C'est l'affaire de deux ou trois jours pour que ça arrive en mise à jours officiel.
Plus généralement.
On est ici, pour beaucoup, amoureux d'Unix/Linux. C'est astucieux et clean. On s'est bien pris la tête pour comprendre comme ça marche sous le capot et ça nous a été très profitable.
Notre "amour" fait qu'on pense Unix et qu'on est rétissant à d'autres solutions. Souvent à juste titre. Mais parfois on est rétissant à d'autres solutions car elles demandent de se remettrent en cause.
On ne le devrait pas toujours. Par exemple OLPC est un Linux, son modèle de sécurité est complètement différent d'un Unix (OLPC utilise aussi SeLinux :-)).
Il n'est pas question de dire que SeLinux est indispensable. Telque le conçois Fedora par exemple, un système doit rester sûr sans SeLinux (au moins autant que n'importe quel système sans SeLinux).
M'enfin, il est peut-être temps d'aller plus loins que le modèle Unix classique. Si on a un linux pour les masses, on ne va pas demander à tous les utilisateurs d'être un expert Unix ou d'avoir de bons fondamentaux en Unix. Si Linux devient le système le plus utilisé, il y aura plein programmes tous plus flashy les uns que les autres à downloader. Sous Windows ce sont souvent des spyware/etc et il faut un anti-virus. Si on veut répondre à ce problème qui se posera, il faut aller plus loins que le modèle Unix classique.
Bien des évolutions se sont faites avec des résistances. Bien des distributions on mis des mois (pour ne pas dire années) pour passer à UTF ou pam. De nombreux utilisateurs préféraient s'ajouter au groupe "sound" que de laisser pam_console s'occuper de ça (maintenant c'est ConsoleKit l'avenir (c'est dans déjà utilisé par F8)).
Rester cramponné à nos habitudes/traditions n'est pas toujours bon. D'autant plus que SeLinux ne diminue jamais la sécurité ! Il n'autorise jamais ce que Linux sans SeLInux refuserait.
Es-ce que l'avenir sera SeLinux ?
J'en sais rien. Mais j'ai du mal à croire que le modèle actuel Unix sera satisfaisant à l'avenir.
Pour le fun. J'ai Firefox qui a planté il y a 2 minutes. Il a déclenché SeLinux. Comme il y a audit et setroubleshooting, j'ai une applet qui clignote. Je clique, et j'ai un diagnostique (tout n'est pas traduit encore) :
Il faudrait que l'utilisateur puisse modifier des règles pour les programme qu'il lance lui-même sans passer par root (l'utilisateur à toujours le droit de faire des connerie si il insiste). C'est prévu à moyen terme par SeLinux.
[^] # Re: Pourquoi une option ?
Posté par IsNotGood . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 4.
> S'il s'agit du desktop, où l'ensemble des logiciels fournis par le distributeur suffisent généralement à l'utilisateur, tout à fait (et pour les logiciels non fournis par la distribution, donc sans règles SELinux, on sera tolérant en considérant que les desktop est généralement moins critique que les serveur).
SeLinux débute pour le desktop. Mais les possibilités sont énormes. Par exemple si un utilisateur lance un programme dans son $HOME, on peut faire que ce programme (qui a été downloadé sur un signe warez) ne puisse lire .thunderbird, etc...
A l'avenir (car SeLinux débute dans le domaine du desktop), les paquets rpm/deb qui sont installés et ne sont pas signés par une source de confiance pourront avoir des privilèges limités (interditions de lire/écrire/supprimer des fichiers que le programme n'a pas créé, etc). Notons qu'un "bête" rpm est un problème puisqu'il s'installe avec les droits root.
[admin@one rsync]$ rpm -q --scripts firefox
postinstall scriptlet (using /bin/sh):
update-desktop-database /usr/share/applications
preuninstall scriptlet (using /bin/sh):
# is it a final removal?
if [ $1 -eq 0 ]; then
/bin/rm -rf /usr/lib/firefox-2.0.0.9/components
/bin/rm -rf /usr/lib/firefox-2.0.0.9/extensions
fi
postuninstall scriptlet (using /bin/sh):
update-desktop-database /usr/share/applications
Le "rm -rf" pourrait être un "rm -rf /", il marcherait très bien.
Donc dans les scripts d'installation tu peux faire tout et n'importe quoi et sous le compte root. Avec SeLinux tu peux gérer ce type de problème. Problème qui se posera à l'avenir.
> Ainsi les applications critiques exposés au réseau ne seront finement protégés qu'à condition que l'admin écrive ou affine lui-même ses règles SELinux.
Le httpd de Fedora avec SeLinux n'a pas le droit de lire /etc (sauf /etc/httpd et quelques bricoles) ni les fichiers dans /tmp (sauf ceux créés par apache).
Il y a plein de "petites choses" dans ce gout. Et tu as ça par défaut !
Tu as ça aussi si l'administrateur à fait des conneries (par exemple un malheureux chmod -R 777 /etc). Si un utilisateur à fait chmod -R 777 ~, ben apache (ou un script d'apache) ne pourra pas y lire.
Si tu utilises mod_user (avec ou sans suexec) d'apache ça veut alors dire que $HOME/public_html est accessible. Et donc $HOME. Et donc tous les fichiers à l'intérieur dès que l'utilisateur fait un oubli. SeLinux gère ça. apache ne peut lire et écrire que dans $HOME/public_html quelque soit les conneries de l'utilisateur.
Il y a des tonnes de serveur prétendument "finenement protégé" qui ne sont pas au niveau de ce qui est fait par SeLinux sous Fedora par défaut. Par défaut sans que tu te prennes la tête. Et l'expertise que tu as n'est pas d'un administrateur qui a fait ça à l'arrache car il est sous pression, mais par des experts.
> Et là, la complexité est un handicap
La complexité est toujours un handicap/problème. Mais es-ce Selinux qui est complexe ou la sécurité qui est complexe ?
Avec chroot, les droits DAC, aussi ACL, des programmes bien sélectionnés et audités, etc et un admistrateur compétent tu peux avoir un système très sûr. Aucun doute sur ça. Pour ces cas on n'a pratiquement pas besoin de SeLinux. Ces cas sont finalement très limité.
Par contre dans pleins pleins d'autre cas, SeLinux est un atout. Ce n'est pas un atout qui ajoute forcément de la compléxité. J'ai installé bugzilla et awstats, il y a déjà des règles SeLinux, j'ai rien à faire. Plus simple que ça tu meurs.
Pour les cas spécifiques ?
Ben il y aura du boulot. Oui. Mais au lieux de te prendre la tête pour mod_user, pour bugzilla, pour awstats, etc, ben tu ne te prends la tête que pour les choses très spécifiques.
Il y a une communauté SeLinux très dynamique, tu trouveras de l'aide sans problème. SeLinux est aussi l'outil qui répond à une très vaste palette de problème (bien au-delà de ce que proposer le modèle DAC, ACL, chroot, etc). Donc au-lieu de te demander qu'elle solution il te faut dans les 10 000 addons sécurité, il te suffit de connaitre SeLinux. Ça simplifie grandement. Donc la complexité de SeLinux est très relative. D'autant plus qu'on a de plus en plus d'outil de haut niveau pour faire ses propres règles ou pour faire un audit rigoureux des règles (atout énorme de SeLinux).
SeLinux te permet aussi d'exprimer ton besoin (domaine, object, attribut, etc) et celà aussi ça simplifie la vie lorsque la situation est complexe.
[^] # Re: Pourquoi une option ?
Posté par IsNotGood . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 0.
Les devs SeLinux sont "odieux" envers les fausses solutions (type AppArmor). Ils ne sont pas odieux vis-à-vis de ce qui est techniquement bien conçu (par exemple smack).
Et s'ils étaient aussi odieux que tu le dis, aussi odieux que Theo par exemple, SeLinux ne serait pas upstream.
[^] # Re: Pourquoi une option ?
Posté par IsNotGood . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 0.
Oui. Mais Selinux ce n'est pas 5 % de perte en performance (ni 7 % comme le dit (ou l'a dit) Novell).
Dans quelques scénarios très spécifiques on peut monter à 3 % (cas où on accède à 10 000 fichiers différents par seconde et où SeLinux doit contrôler chaque accès). Généralement on ne remarque rien de rien. Il y a eu un bench entre Ubuntu et Fedora pour les jeux. La différence : 0,00000.
[^] # Re: Pourquoi une option ?
Posté par IsNotGood . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 1.
Inversement, beaucoup utilise le noyau/glibc "full feature" au niveau sécurité livré par la distribution sans s'en préoccuper. C'est le cas de Fedora par exemple.
> Il faut rajouter à ça qu'une simple activation de SELinux ne suffit pas.
Ça dépend comme est intégré SeLinux. Un noyau SeLinux sans règle de sécurité SeLinux est sans intérêt.
> Il faut chercher à comprendre ce que propose ce mécanisme et comment le configurer correctement
Ça dépend. Pour Fedora, dans la majorité des cas tu ne te soucis pas de ça et c'est déjà configuré. D'autres (des spécialistes) configurent Selinux pour toi comme les permissions de fichier sont déjà configurées dans toutes les distributions par exemple.
> ce qui n'est ni à la portée de tous
Effectivement.
> Ainsi, on risquerait fort de donner une fausse impression de sécurité en posant une configuration "générique" de SELinux par défaut, ce qui est encore plus dangereux que ne rien mettre du tout à mon avis.
Remarque très pertinente.
La sécurité ne se résume à un bouton sur on ou off.
Mais je te conseille, si tu as le temps, de regarder Fedora. SeLinux y est intégré et le travail ne c'est pas limité à configurer une option du noyau.
> S'il est suffisament compétent pour activer et paramétrer SELinux, il le fera de lui-même, et bien mieux que toute configuration préfabriquée.
J'en doute.
SeLinux (ses règles de sécurité) est un travail énorme (des années). Je ne crois pas d'un administrateur s'improvise expert Selinux du jours au lendemain.
Quelques liens pour voir en surface le travail réalisé par Fedora/RH :
http://www.redhatmagazine.com/2007/05/04/whats-new-in-selinu(...)
http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guid(...)
[^] # Re: Pourquoi une option ?
Posté par IsNotGood . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 1.
C'est le cas.
> Mais je parlais dans le sens général d'une installation par défaut d'un utilisateur standard.
Peut-être que je t'ai mal compris. Mais tous les trucs précédents sont activés par défaut (même SeLinux (dans un mode qui est presque strict)). Donc tu installes une Fedora ou une RHEL (ou CentOS, etc), et voilà.
C'est un démaine où Fedora est en pointe :
http://fedoraproject.org/wiki/Security/Features
Et tu as raison de le dire, il ne sagit uniquement d'appliquer quelques patch pour dire "on a ça", mais il faut que ça soit activé et utilisable dans la majorité des configurations. C'est le cas.
C'est un énorme travail. En passant, F8 a la fonctionnalité "compte visiteur" par défaut (grace à SeLinux) :
http://danwalsh.livejournal.com/13376.html
C'est un bon début.
[^] # Re: Pourquoi une option ?
Posté par IsNotGood . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 2.
SeLinux est en standard.
> Pourquoi ce qui s'applique aux BSD ne fait figure que d'option sous Linux ?
Linux n'est qu'un noyau.
Certaine distribution renforce la sécurité.
Pour exemple pour Fedora/RH. il y a tout un tas de truc auquel je ne comprend pas grand chose et qui est parfois upstream :
* Default requires signed updates
* NX emulation using segment limits by default
* Support for Position Independent Executables (PIE)
* ASLR for Stack/mmap by default
* ASLR for vDSO (if vDSO enabled)
* Restricted access to kernel memory by default
* NX by default for supported processors/kernels
* Support for SELinux
* SELinux default enabled with targetted policies
* glibc heap/memory checks by default
* Support for FORTIFY_SOURCE, used on selected packages
* All packages compiled using FORTIFY_SOURCE
* Support for ELF Data Hardening
* All packages compiled with stack smashing protection
* Pointer encryption
Vous trouverez des pointeurs vers plus d'info ici :
http://www.awe.com/mark/blog/200701041544.html
En passant, car ce n'est pas indiqué dans cette liste, les noyaux Fedora/RH on un contrôle de signature (gpg) lors du chargement des modules. Présent dans Fedora mais peu (voire pas) utilisé pour Fedora.
[^] # Re: limite théorique...
Posté par IsNotGood . En réponse à la dépêche Le Top500 nouveau est arrivé. Évalué à 5.
[^] # Re: LSM
Posté par IsNotGood . En réponse au journal Le nouveau SeLinux. Évalué à 1.
Tu préfères Windows ? HP-UX ? Solaris ?
[^] # Re: LSM
Posté par IsNotGood . En réponse au journal Le nouveau SeLinux. Évalué à 1.
Tu bosses à la poste ou c'est toi qui a choisi la source ?
> Manque de bol ce n'est pas Alan qui décide mais Linus.
Pourquoi manque de bol ?
Linus n'est pas là par hazard.
Le travail fournit par SeLinux est titanesque. L'éventualité que Linus soit d'accord pour virer LSM plane depuis 2005 je crois. Si Novell passe à SeLinux (ce que je crois), on n'aura une belle proportion de codeur Linux qui bosse pour une boite qui veut SeLinux. Si Linux accèpte AppArmor ou smack ou autre, il y aura de l'électricité dans l'air. Je crois que va dépasser l'incident diplomatique. J'ai du mal à imaginer ce qui va se passer.
> que tout le monde ne semble pas avoir le même avis que les devs de SeLinux.
Surtout les concurrents de SeLinux. J'y revient, mais "tout le monde" c'est qui ?
Que OOXML arrive a avoir un nombre respectable de vote à l'ISO, n'implique pas que je dois penser qu'OOXML est du bon matos et que finalement il lui faut la certification ISO comme ODF a la certification ISO.
Il y a qui et avec quel argument.
Les pro-OOXML peuvent être nombreux, pour moi ça ne change rien car les arguments (OOXML) sont nazes.
Les choix du noyaux doivent être principalement être motivé par les mérites techniques et non car telle ou telle solution est populaire. On est pas sur TF1.
Le seule reproche de SeLinux est la complixité. C'est compliqué mais ce que fait SeLinux est compliqué. C'est comme reprocher au code de gcc d'être compliquer. gcc est compliqué car ce qu'il fait est compliqué (optimisation, multi-language, cross-compilation, etc).
Ce n'est pas car je peux éditer à la main les règles de SeLinux que je dois savoir le faire pour profiter de SeLinux.
Comme ce n'est pas parceque j'ai les sources de Linux que je me sens obligé de bidouiller Linux lorsque je veux une fonctionnalité.
Lorsqu'on veut changer un paramètre de Linux (par exemple sa table de routage), je ne code pas des appels systèmes, je ne code pas des appels de fonction à la libc, je ne fais pas des scripts shell qui appellent ifconfig et route, j'utilise des outils de plus haut niveau (rc.* qui fait ça automatiquement, ou NetworkManager, etc). Sûr qu'aujourd'hui au moins 90 % des utilisateurs ne save pas utiliser ifconfig et route et encore moins coder des appels systèmes.
Ce qui est fait pour linux afin d'éditer les tables de routage peut-être fait pour SeLinux pour éditer les règles. Ça me semble évident à comprendre.
Que l'utilisateur final/lambda trouve aujourd'hui SeLinux compliqué a utiliser est logique. Je trouve ça compliqué aussi. C'est logique car le développement d'applis "user-friendly" commence à peine. Car l'architecture des règles commence à peine à être figée, etc. Mais les critiquef de complexité de Selinux venant de développeurs Linux frise le ridicule. Je ne vais pas voter contre iptables car je trouve /sbin/iptables imbitable et que ça fait des choses salement compliquée. Je ne vais pas voter pour iptables car system-config-firewall est simple d'utilisation. Si je suis développeur noyau je vais voter en fonction des fonctionnalités/performances que fournit iptables. Iptables fournit plein de fonctionnalité, il peut faire du compliqué et du simple, je vote pour. SeLinux fournit plein de fonctionnalité, il peut faire du compliqué et du simple, je vote pour. Mais certains dev Linux se mélange les crayons actuellement.
> que tout le monde ne semble pas avoir le même avis que les devs de SeLinux.
S'il y a un vote des codeurs de Linux pour choisir une infrastructure pour la sécurité, SeLinux arrivera probablement en tête. Et pas car les dev de SeLinux seraient majoritaire :-)
Si tu prends AppArmor, il est sévèrement critiqué par les dev Linux. Il reste le nouveau smack. Mais smack se veut simple et que simple. Il ne couvrira qu'un spectre des besoins en sécurité.
> En tout cas cette polémique va forcer Morris et les autres a travailler comme des fous sur l'amélioration de la simplicité d'utilisation de SeLinux car c'est ça qui est perçu comme étant sa grande faiblesse. Ce sera bénéfique pour tous !
Les pauvres. Après tout le boulot et le géni qu'ils ont fournit (gigantesque) on estime qu'ils méritent encore un coup de pied dans cul :-)
[^] # Re: LSM
Posté par IsNotGood . En réponse au journal Le nouveau SeLinux. Évalué à -1.
Ce n'est pas tout à fait ce que je voulais dire. Fedora a peut-être moins de contributeur qu'Ubuntu ou Debian. Mais son niveau globale est assez élevé. C'est mon sentiment.
[^] # Re: SeLinux pour les nuls
Posté par IsNotGood . En réponse au journal Le nouveau SeLinux. Évalué à 1.
Tu veux s'avoir ce que t'apporte SeLinux ?
Clairement dans ce contexte c'est moins intéressant que pour une serveur critique.
> En général, ce que l'on veut pour un poste de travail, c'est vérifier le comportement des applications clientes (à cause des chevaux de troie), comment cela est compatible avec la possibilité de développer ?
SeLinux ce n'est pas que l'id de l'utilisateur. C'est l'id ET d'autres informations. Par exemple es-ce que le processus est un fils de /sbin/login, si c'est via ssh, qu'elle est l'adresse ip, etc. Dont tu peux par exemple avoir des privilèges différents si t'es connecté à la console ou via ssh.
Si ta bécane est attaquée et que le cracker obtient le compte root, il ne peut rien faire si par exemple le compte root n'a pas été obtenu via /sbin/login. Ceci dépend évidemment de la configuration SeLinux. SeLinux c'est une infrastructure, ce n'est pas une politique de sécurité. SeLinux supporte plein de politique de sécurité.
SeLinux fait aussi la distinction entre initialisation de la bécane (configuration des péiphériques, etc) et le moment où est elle est fonctionnelle. Lorsque le boot est terminé, certaines actions ne sont plus possibles.
> Les distributions activant SELinux utilisent quel type de politique de sécurité dans ce cas d'une machine pour développeur ?
Fedora il n'y a pas de distinction (RHEL 5 propose les règles stricts qui ne sont pas adaptées à un poste desktop, mais ses règles vont être abandonnées). Que ce soit un serveur où un desktop c'est grosso-modo la même configuration. Les utilisateurs sont confinés (NB: c'est un domaine où débute SeLinux qui jusqu'à maintenant c'est principalement concentrés sur la partie serveur).
Pour Fedora (ça sera la même chose pour RHEL6) il n'y a deux types de configuration :
- targeted
- mls
targeted (qui devient de plus en plus strict) convient pour les cas classiques (aussi bien desktop que serveur). targeted supporte support les modèles MAC et RBAC. Mls est pour Multi Level Security. C'est pour l'armée, etc... :
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/(...)
MLS est aussi utilisable en poste desktop.