lundi 17 novembre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Derniers journaux de g78 :

Journal : Une petite idée du soir

Posté par Laurent Saint-Michel () le 14 avril 2006
0
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?

> Lire le journal (44 commentaires, moyenne: 2,8).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Une petite idée du soir

Posté par L () le 15/04/2006 à 00:34. (lien). Évalué à 4.

Je pense que tu es un génie !

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

    Posté par Ben (Jabber id, page perso, ) le 15/04/2006 à 01:47. (lien). É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')

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

      Posté par L () le 15/04/2006 à 01:56. (lien). Évalué à 3.

      Euh ... Quand je disais qu'il était un génie, j'étais ironique :)

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

      Posté par Ju. (Jabber id, ) le 15/04/2006 à 05:07. (lien). É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

      --
      Les fans de Ubuntu et leurs CD, c'est comme les Mormons avec leur évangile, ils en ont toujours sur eux à donner, au cas où.
      Zorro.

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

        Posté par alexissoft (Jabber id, page perso, ) le 15/04/2006 à 07:03. (lien). É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 Jean Canazzi () le 15/04/2006 à 07:56. (lien). É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...

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

        Posté par L () le 15/04/2006 à 12:12. (lien). Évalué à 4.

        Sans compter que déjà, quand j'installe des Linux avec un compte d'utilisateur standard (non root), la première question de l'utilisateur c'est si on peut virer le mot de passe lors de la connection. Alors j'imagine même pas s'il doit saisir le mot de passer à chaque opération :)

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

          Posté par Laurent Saint-Michel () le 15/04/2006 à 12:44. (lien). É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 Krunch (Jabber id, page perso, ) le 15/04/2006 à 15:03. (lien). É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.

            --
            Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
            pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

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

      Posté par Croconux () le 15/04/2006 à 10:31. (lien). É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 Thomas Douillard () le 15/04/2006 à 12:38. (lien). É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 Laurent Saint-Michel () le 15/04/2006 à 12:46. (lien). É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 Laurent Saint-Michel () le 15/04/2006 à 13:24. (lien). É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 viking () le 15/04/2006 à 06:49. (lien). É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 Laurent Saint-Michel () le 15/04/2006 à 13:07. (lien). É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 Krunch (Jabber id, page perso, ) le 15/04/2006 à 15:35. (lien). É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(...)

    --
    Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
    pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

    • [^]Re: Quasi mais pas completement.

      Posté par Nicolas Dumoulin (Jabber id, page perso, ) le 15/04/2006 à 17:30. (lien). É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 Ph Husson () le 15/04/2006 à 20:48. (lien). É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 Krunch (Jabber id, page perso, ) le 15/04/2006 à 22:18. (lien). É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).

          --
          Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
          pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

autre idée.

Posté par Gof (Jabber id, page perso, ) le 15/04/2006 à 07:21. (lien). É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 ndv (Jabber id, ) le 15/04/2006 à 08:18. (lien). É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 Sufflope (Jabber id, page perso, ) le 15/04/2006 à 09:13. (lien). É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.

      --
      Le meilleur hébergeur de forums, gratuit et sans pub !

      • [^]Re: autre idée.

        Posté par daggett () le 15/04/2006 à 09:59. (lien). É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 benja () le 15/04/2006 à 10:16. (lien). É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 Ph Husson () le 15/04/2006 à 10:52. (lien). É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 fork_bomb () le 15/04/2006 à 10:20. (lien). É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 Sufflope (Jabber id, page perso, ) le 15/04/2006 à 10:52. (lien). É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.

          --
          Le meilleur hébergeur de forums, gratuit et sans pub !

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

            Posté par benja () le 15/04/2006 à 11:00. (lien). É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 med (page perso, ) le 15/04/2006 à 11:28. (lien). Évalué à 2.

              VMS est libre maintenant ?

              • [^]Re: autre idée.

                Posté par benja () le 15/04/2006 à 11:50. (lien). É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 Ernest H (Jabber id, ) le 15/04/2006 à 11:47. (lien). Évalué à 2.

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

              • [^]Re: autre idée.

                Posté par benja () le 15/04/2006 à 13:05. (lien). É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 Laurent Saint-Michel () le 15/04/2006 à 12:58. (lien). Évalué à 2.

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

      • [^]Re: autre idée.

        Posté par ndv (Jabber id, ) le 15/04/2006 à 14:39. (lien). Évalué à 2.

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

        • [^]Re: autre idée.

          Posté par Erwan (page perso, ) le 16/04/2006 à 06:15. (lien). É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 Ph Husson () le 16/04/2006 à 07:05. (lien). Évalué à 2.

            Ah on a pas encore de technique pour avoir le beurre, l'argent du beurre et la cremiere.

    • [^]Re: autre idée.

      Posté par EmmanuelP () le 15/04/2006 à 15:06. (lien). Évalué à 1.

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

châtrer

Posté par ouah (page perso, ) le 17/04/2006 à 11:48. (lien). É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 Ph Husson () le 17/04/2006 à 18:09. (lien). É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 Jarod_Summers () le 18/04/2006 à 19:26. (lien). É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 ?

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1709s (dont 0.0263 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !