Journal Une petite idée du soir

Posté par  .
Étiquettes : aucune
0
15
avr.
2006
Je viens d'avoir une petite idée pour améliorer la sécurité des données pour le répertoire personnel contenant en général plus de données importantes pour l'utilisateur que tout le reste du système.

L'idée est relativement simple : en gros on efface peut de fichiers alors que l'on conserve, modifie et copie un grand nombre de fichiers dans le même temps.

Ainsi, il faut empêcher d'effacer, sans l'accord express de l'utilisateur, les données sises sur son répertoire personnel. Les autres opérations (déplacement, renommage, copie, création, ...) ne nécessitent aucune autorisation particulière.

L'accord express s'acquiert par la saisie d'un mot de passe.

Pour éviter d'être en permanence bloqué par une telle mesure, on peut penser à un seuil du type : 3 effacement par heures et, au delà, il faut que l'utilisateur retape un mot de passe.

L'administrateur n'est pas épargné de cette manip mais il peut modifier ce genre de comportement (forçage permanent pour la durée d'une session).

En très gros, il s'agit d'un système de fichier en quasi écriture seule.

Qu'en pensez vous?

  • # Commentaire supprimé

    Posté par  . Évalué à 4.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Une petite idée du soir

      Posté par  (site web personnel) . Évalué à 3.

      Je pense qu'il est tard..

      Je ne vois pas l'intéret de cette chose bizarre. Je ne vois surtout que des ennuis à devoir donner mon mdp rien que pour effacer 3 pauvres fichiers temporaires.

      De plus, à priori, les données que tu modfies rarement, tu leur met simplement un mode "400" et tu est obligé de retirer le mode 400 juste pour tes opérations de suppression.

      Sinon, tu peux toujours faire un alias bash sur 'rm' (genre 'rm -i')

      Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Une petite idée du soir

        Posté par  . Évalué à 3.

        C'est pas completement absurde... avec le principe des comptes restreints par defaut sous unix-Gnu/linux ca sera delicat de faire une attaque sur la machine, au niveau systeme mais un virus, une saloperie, un malware quelconque, voire le super script de la mort .sh qui configure automatiquement votre machine pour votre ATI (c'est un exemple donc), lui, pourrait contenir un truc genre rm -rf ~

        Voire pire un find sur ce qui est 'w' pour l'utilisateur et un parcours dessus avec rm.

        Rien n'empeche un utilisateur de se tirer dans le pied.

        Avec l'arrivee du grand public (et c'est tant mieux) un mecanisme desactivable de ce type serait interessant.

        L'alias rm = rm -i vaut pas trop : le script peut tres bien executer /usr/bin/rm

        • [^] # Re: Une petite idée du soir

          Posté par  . Évalué à 3.

          1°/ Quand tu charge un script tu charge un nouvel interpréteur, donc tu perd les alias de la session
          2°/ Un script tourne en non-interactif, et bash n'utilise pas les alias en non-interactif

          Je doute que tu fasse "source ati-config.sh" pour configurer ta carte :)

      • [^] # Re: Une petite idée du soir

        Posté par  . Évalué à 9.

        Le problème c'est aussi que ça risque d'habituer l'utilisateur à rentrer son mot de passe. Il sera moins méfiant quand un script nuisible le lui demande...

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Une petite idée du soir

            Posté par  . Évalué à 1.

            Le but est de ne pas rendre la suprresion de certains fichiers situés dans des répertoires bien spécifiques possible sans action interactive de l'utilisateur. En gros rendre un rm -f impossible pour un script/virus/...

            Parès que cela soit un mot de passe ou un autre système [*] c'est à voir ce qui est le plus simple et le moins contraignant.

            [*] par exemple un boite de dialogue si l'utilisateur est connecté sous X indiquant : le processus A souhaite supprimer les fichiers suivants. Doit-on continuer ?

            • [^] # Re: Une petite idée du soir

              Posté par  (site web personnel) . Évalué à 2.

              Le but est de [...] rendre un rm -f impossible pour un script/virus/...
              Bonne chance alors parce que je vois pas ce qui empèche un malware quelconque de rester daemonisé dans un coin en attendant que l'utilisateur tape son mdp pour une raison légitime histoire de le récupérer pour pouvoir faire son rm tranquillement ensuite.

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Une petite idée du soir

        Posté par  . Évalué à 4.

        Je ne vois surtout que des ennuis à devoir donner mon mdp rien que pour effacer 3 pauvres fichiers temporaires.

        Et accessoirement ca risque de bloquer pas mal de logiciels qui créent des fichiers temporaires et les suppriment ensuite (éditeur de texte au autre). L'utilisateur va se voir spamé de message "Erreur : Impossible d'effacer le fichier G4jFg7Z.tmp~", fichier qu'il ne connait pas. Tous ces fichiers vont s'accumuler et faire gonfler son compte de façon démesurée.

        De plus, à priori, les données que tu modfies rarement, tu leur met simplement un mode "400" et tu est obligé de retirer le mode 400 juste pour tes opérations de suppression.

        J'approuve complètement. Les choses seraient tellement plus simples si les gens étaient moins bordéliques. Les données importantes, on les met dans un dossier "A conserver" avec les droits qui vont bien. Un compte utilisateur, ça se gère comme son chez soi : On ne fout pas ses papiers importants en vrac au milieu d'une pile de prospectus et on viens pas se plaindre quand on a foutu en l'air la dite pile (équivalent du rm -f). On T.R.I.E. C'est incroyable le nombre de solutions technique foireuses qu'on va inventer pour des problèmes d'interfaces clavier-chaise.

        • [^] # Re: Une petite idée du soir

          Posté par  . Évalué à 3.

          Du point de vue protection des données d'un éventuel programme malveillant, ça change pas grand chose, le programme fera un chmod avant de faire le rm, et puis c'est tout. Pour les supressions accidentelles, ça peut aider, c'est sûr.

        • [^] # Re: Une petite idée du soir

          Posté par  . Évalué à 5.

          L'idée n'est de faire cela que pour un ou plusieurs répertoires contenant les données importantes pour l'utilisateur comme, par exemple, home/toto/documents mais pas sur tout le répertoire home.

          Concernant la manip chmod 400, n'importe quel scrip tournant avec les droits de l'utilisateur peut modifier les droits avant d'éffacer ces dits fichiers. C'est donc pas une protection suffisant de mon point de vue.

          Je le précise, peut-être un peu tard, mais le but est de réduire l'impact des virus/script/... sur la protection des données personnelles.

        • [^] # Re: Une petite idée du soir

          Posté par  . Évalué à -1.

          L'idée n'est de faire cela que pour un ou plusieurs répertoires contenant les données importantes pour l'utilisateur comme, par exemple, home/toto/documents mais pas sur tout le répertoire home.

          Concernant la manip chmod 400, n'importe quel scrip tournant avec les droits de l'utilisateur peut modifier les droits avant d'éffacer ces dits fichiers. C'est donc pas une protection suffisant de mon point de vue.

          Je le précise, peut-être un peu tard, mais le but est de réduire l'impact des virus/script/... sur la protection des données personnelles.

  • # Quasi mais pas completement.

    Posté par  . Évalué à 6.

    Ca va t'as bien dormi ? ;)

    Va falloir demander un mot de passe pour l'écriture aussi alors. Car, si un malware ne peut effacer un fichier, il peut le remplir de 0.

    Ton truc ca va plus ennuyer l'utilisateur qu'autre chose.

    Ce qu'il faudrait plutot c'est utiliser la sécurité Unix et avoir une procédure qui permettrait de changer facilement le propriétaire du fichier en demandant le mot de passe d'un compte défini spécialement pour protéger des dossiers importants.
    Pour utiliser ses données, l'utilisateur devrait redonner ce mot de passe et la procédure referais un chown.

    En fait, c'est un système de gestion atomique des droits plus au niveau des services systèmes du système mais aussi au niveau de l'utilisateur. Cette gestion serait en fonction du degré d'importance des fichiers de l'utilsateur. Et cela peut se faire dossier par dossier; un dossier ayant un certain niveau de sécurité.

    • [^] # Re: Quasi mais pas completement.

      Posté par  . Évalué à 1.

      Sur le pproblème de la substitution des fichiers en écriture, tu as raison mais encore un petite nuit et je trouverai peut-être la solution ;).


      Ce qu'il faudrait plutot c'est utiliser la sécurité Unix et avoir une procédure qui permettrait de changer facilement le propriétaire du fichier en demandant le mot de passe d'un compte défini spécialement pour protéger des dossiers importants.
      Pour utiliser ses données, l'utilisateur devrait redonner ce mot de passe et la procédure referais un chown.


      Dans ce casl'utilisateur devrait donner le mot de passe / validation / ... encore plus souvent, non ?

      En plus pendant la durée d'exploitation des données (période de chown), elles sont vulnérables à un effacement, substitution, .... ce qui ne résoud le problème que durant la période ou le chown n'est pas positionné sur l'utilisateur.

    • [^] # Re: Quasi mais pas completement.

      Posté par  (site web personnel) . Évalué à 4.

      AMA la solution c'est plutôt de mettre des droits au niveau des appels systèmes (genre SELinux, AppArmor, Systrace,...) pour chaque programme plutôt que de s'amuser à créer 1000 "sous utilisateurs" par utilisateur. Par exemple il n'y a pas de raison que Firefox écrive quoi que ce soit en dehors de $HOME/.mozilla/ (et éventuellement un répertoire genre $HOME/downloads/) quel que soit l'utilisateur qui l'a lancé.

      http://www.nsa.gov/selinux/
      http://en.opensuse.org/AppArmor_Detail
      http://www.systrace.org/

      Il y a aussi le modèle de sécurité de Plan9 qui est intéressant.
      http://web.archive.org/web/20040222164219/cm.bell-labs.com/s(...)

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Quasi mais pas completement.

        Posté par  (site web personnel) . Évalué à 2.

        Par exemple il n'y a pas de raison que Firefox écrive quoi que ce soit en dehors de $HOME/.mozilla/ (et éventuellement un répertoire genre $HOME/downloads/)


        Tout à fait !
        En fait, moi une fois sous la douche (c'est plutôt là que mes idées surgissent), je me suis dit qu'il faudrait pouvoir limiter les droits d'un programme facilement. Un peu comme un pare feu, genre toi t'as le droit de lire là, d'écrire ici et c'est tout. Mais bon en pratique, je ne vois pas trop comment faire ... à part effectivement créer 1000 utilisateurs et groupes, mais bon après tout ! Un user par application "connue" + un pour les applications inconnues (genre le script fraîchement téléchargé, ou un truc de test).

        Mouaif, v'là mes deux centimes, mais je comprends pas tout à ce que je dis :-/ Je vais peut-être aller prendre une douche tiens !

        • [^] # Re: Quasi mais pas completement.

          Posté par  (site web personnel) . Évalué à 3.

          Bwah "facile"
          comme le dit monsieur un module genre SELinux et basta (par contre on définit quelle appli est qui comment ? son path? son pid? son argv[0] ? Une clé privée?

          • [^] # Re: Quasi mais pas completement.

            Posté par  (site web personnel) . Évalué à 2.

            L'authentification des programmes est faite par leur chemin d'accès complet (évidemment pour les scripts en #! c'est un peu la foire).

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # autre idée.

    Posté par  (site web personnel) . Évalué à 8.

    Bon, voici une autre idée.
    Elle est assez consommatrice en espace disque et en ressource, mais bon.

    L'idée est d'avoir sur /home un système de fichier qui gère les versions, à la subversion.

    Ça a bcp d'avantages comme la possibilité de revenir en arrière en cas de fausse manipulation (y compris par un virus).

    Bon, évidemment ça prends de l'espace disque, mais on est pas obligé de garder l'historique depuis le début, on peux effacer l'historique après une semaine.

    • [^] # Re: autre idée.

      Posté par  . Évalué à 7.

      Moment culture microsoftienne.

      Depuis Windows 2003 serveur, il est possible d'activer un système de "Versions précédentes".

      Pour l'utilisateur, cela se traduit par un nouvel onglet dans la fenêtre de propriétés d'un fichier. Dans celui-ci, on peut récupérer le fichier tel qu'il était il y a 4 heures, 8 heures, etc. Tout cela est bien sur paramétrable.

      Ce n'est pas activé par défaut. Windows ne sauvegarde que les différences de manière incrémentale, donc ça ne prend pas trop de place.

      • [^] # Re: autre idée.

        Posté par  (site web personnel) . Évalué à 1.

        Un peu d'honnêteté ne fait pas de mal : bravo Microsoft. J'connais pas de distrib où il y ait un truc comme ça.

        • [^] # Re: autre idée.

          Posté par  . Évalué à 8.

          Le versionning des fichiers, c'est aussi fait par VMS, depuis 30 ans...
          http://fr.wikipedia.org/wiki/VMS

        • [^] # Re: autre idée.

          Posté par  . Évalué à 2.

          Plan 9 le fait aussi depuis belle lurette. Il était prévu pour fonctionner avec un WORN (write once, read many). L'idée c'est qu'un bloc de donnée n'est jamais effacable et est uniquement identifiable par un hash. Cela permet de recycler des blocs dans des versions consécutives de fichiers.
          Aussi, de mémoire, il y a un service qui archive les fichiers dans une arborescence qui décrit la date de la version et qu'il suffit alors de monter dans son propre namespace pour se retrouver avec la version choisie des fichiers.

          • [^] # Re: autre idée.

            Posté par  (site web personnel) . Évalué à 2.

            Dans le genre y a UDF le systeme des DVD, aussi utilisé pour les "CD disquettes" sur CD-R (ben oui sur un cdr on peut rajouter qqc au bout, mais enlever c'est plus dur)

        • [^] # Re: autre idée.

          Posté par  . Évalué à 1.

          Le principe d'UNIX, c'est que le système est simple et on rajoute des programmes dessus pour faire des trucs. Donc toute distro fournie avec rcs et companie fait ça.

          • [^] # Re: autre idée.

            Posté par  (site web personnel) . Évalué à 3.

            Plan9 et VMS c'est des distribs GNU/Linux ?
            Là si j'en crois le commentaire au-dessus j'ai qu'à choisir l'onglet dédié dans les propriétés du fichier, après avoir activé une option (j'ai jamais touché de W2003).
            Alors oui je sais je peux installer un serveur subversion faire une manip capillotractée sur /home pour que ça marche bla bla. Je peux aussi ne pas savoir le faire et trouver que la case à cocher c'est pas mal.

            • [^] # Re: autre idée.

              Posté par  . Évalué à -1.

              En effet, ce ne sont pas des distrib gnu/linux mais par contre ce sont bien des OS libres (et un "unix" pour plan9) et ils l'ont fait + de 10 ans avant microsoft.

              • [^] # Re: autre idée.

                Posté par  . Évalué à 2.

                VMS est libre maintenant ?

                • [^] # Re: autre idée.

                  Posté par  . Évalué à 1.

                  Méa culpa, j'aurais du vérifier. J'ai déduit du Open de vms qu'il était libre. Il n'empêche qu'il est gratuitement disponible sous quelques conditions. Plan9 est libre lui aussi depuis quelques temps (il y a aussi qq restriction s/ la licence mais dans l'esprit il est libre).

              • [^] # Re: autre idée.

                Posté par  (site web personnel) . Évalué à 2.

                plan9 n'est pas vraiment un unix : c'est censé être un successeur d'unix.

                • [^] # Re: autre idée.

                  Posté par  . Évalué à 1.

                  C'est pour cela que je avais mis unix entre guillemets... Sinon sa phylosophie de conception est quand même d'étendre et d'améliorer les bons concepts d'unix et de repenser ceux qui sont bancaux (cf. l'unix haters book).

      • [^] # Re: autre idée.

        Posté par  . Évalué à 2.

        Question de béotien: et quand on efface le fichier on perd les sauvegardes incrémentales ?

        • [^] # Re: autre idée.

          Posté par  . Évalué à 2.

          Oui. Mais on les retrouve en restorant le dosser parent.

          • [^] # Re: autre idée.

            Posté par  . Évalué à 1.

            Donc du coup, quand on efface un fichier ca n'augmente pas l'espace libre sur le disque. C'est ca ?

      • [^] # Re: autre idée.

        Posté par  . Évalué à 1.

        Avec les unix, on peut faire ça: http://www.rsnapshot.org/

    • [^] # Re: autre idée.

      Posté par  (site web personnel) . Évalué à 7.

      C'est pas comme si ça existait pas déjà...
      FUSE:
      http://cvsfs.sourceforge.net/
      http://n0x.org/copyfs/
      http://wayback.sourceforge.net/

      LD_PRELOAD:
      http://svn.clifford.at/shadowfs/trunk/ (cowfs)

      Hurd:
      http://hurdextras.nongnu.org/#cvsfs
      (+tous ceux de FUSE via libfuse)

      9P (dont il existe au moins 5 implémentations plus ou moins portables):
      http://en.wikipedia.org/wiki/Fossil_(file_system)

      ZFS: http://en.wikipedia.org/wiki/ZFS#Snapshots

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: autre idée.

        Posté par  . Évalué à 3.

        C'est implémenté par défaut dans quelle distrib ?

        • [^] # Re: autre idée.

          Posté par  (site web personnel) . Évalué à 2.

          FUSE semble packagé dans la plupart (toutes ?) les distros récentes (et aussi dispo sous FreeBSD apparement).

          v9fs est intégré à Linux depuis le 2.6.14 par contre je trouve pas l'userland (npfs) ni dans Debian ni Ubuntu.

          ZFS est intégré à Solaris et donc Nexenta.

          Et évidemment il y a GNU/Hurd et Plan9.

          A priori il n'y a que dans Solaris et Plan9 que c'est vraiment disponible par défaut sans configurer quoi que ce soit (enfin, pour ZFS il faut dire explicitement qu'on veut un snapshot apparement).

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # châtrer

    Posté par  (site web personnel) . Évalué à 2.

    Vu que personne n'en a encore parlé, il y a aussi la commande chattr, disponible avec plusieurs fs, qui fait l'affaire.

    • [^] # Re: châtrer

      Posté par  (site web personnel) . Évalué à 1.

      La plupart des FS "Linux" en fait
      XFS le supporte, reiserfs aussi (faut rajouter -oattrs qd meme), ext2|ext3 de ce que je saches
      Surement d'autres

  • # Une autre méthode

    Posté par  . Évalué à 1.

    ce serait possible de n'autoriser une appli qu'a écrire/effacer des données dans son seul repertoire de données ?
    genre Firefox seulement autorisé à modifier /home/user/.firefox
    script-malicieux.sh ne pourrait que écrire dans /home/user/script-malicieux/
    A ca, on rajoute que telle appli a tel quota max pour que le script malicieux ne remplisse pas le dur.
    Z'en pensez quoi ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.