• [^] # Re: Pourquoi une option ?

    Posté par . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 1.

    > (pour revenir sur le troll de l'autre journal).

    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.