Journal Ubuntu pas très sécurisée...

Posté par  .
Étiquettes :
-2
24
août
2008
Il n'y a pas longtemps, je me retrouve sur un poste de travail qui n'est pas le mien.
Je découvre que mon prédécesseur avait installé une Ubuntu (7.10 si je ne m'abuse).

N'ayant pas le mot de passe je décide de passer en "recovery mode" au démarrage.
Et là devant mes yeux ébahis je me retrouve logué en root !
Inutile de dire que quelques lignes plus tard je me retrouvais logué sous la session de mon prédécesseur...

Je ne sais pas si le problème a été corrigé dans la dernière version 8.10 mais c'est un peu gênant.

Autrefois j'installais des Ubuntu par paquet dans des centres informatiques, je crois que je m'y réfléchirais à 2 fois maintenant...

  • # mouarf

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

    Tu sais, tu reinstalles une distrib sans reformater le disque, ou tu utilises un liveCD ... et tu peux acceder aux données de ton predecesseur.
    Il me semble que quasiment toutes les distributions ont des " lacunes " à ce niveau.

    L'ubuntu bashing est facile, mais as tu seulement essayé sur d'autres distrib ?

    Et un recovery mode à quoi sert il ?
    N'est ce pas à ton niveau que tu te trompes sur le role du recovery mode ?
    Car comment passer en recovery mode si /etc/passwd et /etc/shadow sont corrompu ?
    yet another stupid password ?

    Quand j'arrete d'utiliser une machine, je m'assure que mon /home n'est pas trop facilement récupérable ...

    tu vois ou est le soucis ?
    Il n'est pas dans Ubuntu, il est dans la politique de sécurité de la boite qui ne gere pas correctement son parc et dans ton predecesseur qui n'a que faire de ses données et de l'usage qui en etre fait.

    • [^] # Re: mouarf

      Posté par  . Évalué à 10.

      J'ajouterai juste qu'avec toutes les distributions, pour peu qu'on puisse modifier les paramètres passés au noyau au démarrage (on le peut par défaut sur Grub et Lilo), on peut se contenter de rajouter l'option "init=/bin/sh" au noyau pour avoir un accès root.

      • [^] # Re: mouarf

        Posté par  . Évalué à 1.

        Ou alors on peut aussi ajouter l'option single (ce que fait l'entrée d'ubuntu je crois)

    • [^] # Re: mouarf

      Posté par  . Évalué à 5.

      Même après formater, tu fous un photorec et tu trouveras plein plein de données :)

      • [^] # Re: mouarf

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

        désolé, j'aime bien vérifier en écriture les badblocks en même temps que je fais un formatage ;)

    • [^] # Re: mouarf

      Posté par  . Évalué à 8.

      Il me semble que quasiment toutes les distributions ont des " lacunes " à ce niveau.

      Tu peux même dire « tous les systèmes », à moins d'utiliser un FS chiffré.

    • [^] # Re: mouarf

      Posté par  . Évalué à 0.

      tu vois ou est le soucis ?
      Il n'est pas dans Ubuntu, il est dans la politique de sécurité de la boite qui ne gere pas correctement son parc et dans ton predecesseur qui n'a que faire de ses données et de l'usage qui en etre fait.

      Il est surtout dans la politique d'Ubuntu, qui a choisi délibérément de faire une distrib' ouverte, ce qui se tient à peu près sur une machine personnelle. Mais faire une distribution orientée newbie et dire ensuite que c'est de la faute de l'utilisateur s'il n'a pas sécurisé lui-même son système après installation, c'est un peu gonflé.

      Ubuntu est effectivement une distribution qui, par défaut, est peu sécurisée. On en avait déjà trollé parlé, notamment avec l'histoire du sudo en mode graphique qui ouvrait une session en tant qu'unknown et qui pouvait donc être exploitée par toute autre application graphique latente ( http://linuxfr.org//2007/08/20/23014.html ). Et effectivement, sur la plupart des postes personnels, le danger vient plus du réseau que de la console.

      Et un recovery mode à quoi sert il ?

      Ce qui l'ennuie, c'est que n'importe qui puisse déclencher le recovery mode.

      • [^] # Re: mouarf

        Posté par  . Évalué à 1.

        Ce qui l'ennuie, c'est que n'importe qui puisse déclencher le recovery mode.

        Tu veux que l'utilisateur soit défini dans le /etc/passwd pour pouvoir récupérer les données quand le fichiers est corrompu ?

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: mouarf

          Posté par  . Évalué à 2.

          1) Moi, je ne veux rien du tout.

          2) C'est pas de ça qu'il s'agit. C'est le fait que n'importe qui puisse démarrer facilement en mode recovery et avoir un diese immédiatement. Et c'est vrai qu'en soi, ça peut faire peur, surtout si c'est sur un grand parc de machine.

          3) On a déjà dit dans d'autres commentaires qu'il suffit de mettre un mot de passe à grub pour protéger certaines entrées, et au pire, tu les vires et tu restaures ta machines avec un Live CD ... que Ubuntu fournit !

          • [^] # Re: mouarf

            Posté par  . Évalué à 3.

            C'est pas de ça qu'il s'agit. C'est le fait que n'importe qui puisse démarrer facilement en mode recovery et avoir un diese immédiatement. Et c'est vrai qu'en soi, ça peut faire peur, surtout si c'est sur un grand parc de machine.

            Si tu installes un grand parc de machine, tu fait un peu attention à ce que tu installes et il suffit de virer une ligne dans grub.conf pour ne pas y avoir accès facilement.

            On a déjà dit dans d'autres commentaires qu'il suffit de mettre un mot de passe à grub pour protéger certaines entrées

            Donc, il suffit de le mettre si tu veux protégéer mais si tu met un mot de passe sur une entrée que tu n'utilise pas souvent, l'utilisateur moyen ne s'en souviendra plus quand il faudra l'utiliser et ça ne servira à rien.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: mouarf

              Posté par  . Évalué à 1.

              Dis-moi, est-ce que tu lis les commentaires avant d'y répondre ?

  • # Accés physique = root local

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

    Dés que tu as un accés physique illimité sur une machine, tu deviens rapidement root sur cette machine.
    Tu peut passé des arguments au kernel via le bootloader (rw init=/bin/sh), booter sur un livecd et modifié le fichier /etc/shadow, demonter physiquement le hdd et le montre dans ta machine qui a tous les outils de forensics, etc ...

    La seule securité qui tienne un peu, c'est le codage du rootfs.
    Mais avec les attaques physiques sur la RAM, c'est déjà moins sur.

    • [^] # Re: Accés physique = root local

      Posté par  . Évalué à 2.

      les attaques physiques sur la ram ??? wahou, ça à l'air cool ! c'est quoi ce truc ?

      Sinon pour mac-os c'est hyper facile d'avoir l'acces root.
      Il suffit de faire une combinaison de touche au démarage et on l'a

      Après j'ajoute une ligne à sudoers via 'visudo' et un reboot et hop on a l'acess root

      • [^] # Re: Accés physique = root local

        Posté par  . Évalué à 5.

        les attaques physiques sur la ram ??? wahou, ça à l'air cool ! c'est quoi ce truc ?

        Les mémoires standard ont une rémanence assez surprenante après coupure de l'alimentation, de l'ordre de quelque seconde jusqu'a plusieurs minutes si on les refroidit bien.

        Donc pif paf tu reboot express, tu évite le reset a zéro de la ram au démarrage, du fait un dump, et toutes les données de ton fs crypté qui ont transité et resté en tampon dans la ram sont encore là. Ou sinon, si tu peux ouvrir la machine, tu récupère les barettes et tu les utilise dans ton matos a toi.

        Faut aller vite, mais c'est faisable a priori. ( http://en.wikipedia.org/wiki/Data_remanence#Data_in_RAM )

        • [^] # Re: Accés physique = root local

          Posté par  . Évalué à 10.

          (vous êtes des malades)


          ^^

        • [^] # Re: Accés physique = root local

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

          C'est faisable, pas juste a priori :

          http://linuxfr.org/~palm123/26212.html

        • [^] # Re: Accés physique = root local

          Posté par  . Évalué à 2.

          c'est pour ça (et pour d'autres raisons) que quand on code une appli qui manipule des données sensibles (mots de passe, codes de cartes bleues...), il ne faut pas stocker la chaine directement en mémoire mais au une version chifrée. Lors d'un audits de sécurité d'une application, ce n'est pas rare que quelqu'un fasse un dump de la mémoire du processus et cherche un mot de passe dedans.

          • [^] # Re: Accés physique = root local

            Posté par  . Évalué à 2.

            Elle est forcement à un moment en mémoire non ? (Si on utilise pas les trucs genre TPM). Il faut surtout faire gaffe à réecrire la mémoire le plus tôt possible j'imagine.

            • [^] # Re: Accés physique = root local

              Posté par  . Évalué à 1.

              Elle est forcement à un moment en mémoire non ?

              Pas obligatoirement, tu pourrais programmer ton système de manière à coder le mot de passe à la volée à chaque nouveau caractère lu de manière à ne jamais avoir le mot de passe en entier en mémoire.
              Mais il faut pouvoir contrôler complètement le processus de saisie du mot de passe, pas question de compter sur une zone de mot de passe de ton toolkit.

    • [^] # Re: Accés physique = root local

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

      Surtout que trucbuntu n'est pas la seule distribution à avoir cette politique du "recorvery mode".

    • [^] # Re: Accés physique = root local

      Posté par  . Évalué à 1.

      Si on a un accès physique limité (juste se servir du clavier/souris/écran), on ne devrait pas pouvoir être root aussi facilement, pourtant c'est ce qui lui est arrivé. Le problème est que le mode recovery est sans protection (ou qu'on peut passer les paramètres du noyau qu'on veut à un bootloader mal configuré).

      • [^] # Re: Accés physique = root local

        Posté par  . Évalué à 5.

        En tant que distribution clairement orientée desktop, je ne vois pas le souci de ne pas faire de différence entre "accès physique limité" et "accès à la tour". Je ne vois pas non plus le problème de considérer l'accès physique comme étant sécurisé par d'autres moyens.

        • [^] # Re: Accés physique = root local

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

          Personnellement, je ne crains pas beaucoup les vols pour mon ordinateur portable (dans mon utilisation standard), je ne crains pas non plus que quelqu'un le démonte en 2secondes. Ceci dit, il y a un certain de personnes qui seraient contentes d'être root. Alors pour les laptops, je trouve ça bien un mot de passe bios et pas d'accès root sans mot de passe.

          • [^] # Re: Accés physique = root local

            Posté par  . Évalué à 3.

            Idem je met un pass bios sur mes portables.
            Par contre je ne suis pas sur mais il me semble qu'enlever la pile de la carte mêre permet de supprimer le pass. Quoi qu'il en soit ça suffit à faire les pieds au petit malin qui voulait juste me le voler et qui n'a pas de grandes compétences info.

  • # Accès physique.

    Posté par  . Évalué à 10.

    Lorsque tu a un accès physique à une machine, toutes les protections logicielles sont vaines.

    • [^] # Re: Accès physique.

      Posté par  . Évalué à 1.

      Bon, je suis bien d'accord avec vous tous.
      ;o)

      Seulement, qu'on se comprenne bien, je ne suis pas (trop) parano, et je ne cherche pas à tout prix à sécuriser les accès à mes données.
      J'ai bien conscience de ce qu'il est possible de faire avec un peu de bonne volonté....

      Mais dans le cas présent, je ne parle pas d'une manipulation compliquée.
      Je parle de sélectionner une simple option accessible, par défaut à n'importe quel utilisateur, qui me fait passer en root sur la machine!

      Par exemple, sous Windows (2000 et xp pro), je ne suis pas sûr que le mode sans échec te permette d'avoir les mêmes accès. (à confirmer).


      J'ai installé une OpenSuse sur le poste, je testerai si je peux faire de même.

      • [^] # Re: Accès physique.

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

        Booter sur un live CD c'est encore plus simple (t'as une gui), accessible par défaut sur la plupart des ordinateurs...
        Et bon mettre un init=/bin/bash c'est à peine plus compliqué ...

      • [^] # Re: Accès physique.

        Posté par  . Évalué à 4.

        Par exemple, sous Windows (2000 et xp pro), je ne suis pas sûr que le mode sans échec te permette d'avoir les mêmes accès. (à confirmer).

        Si, c'est le cas, et c'est assez pratique en maintenance. :)

        • [^] # Re: Accès physique.

          Posté par  . Évalué à 1.

          En mode sans echec il faut avoir le login/mot de passe, sinon tu n'as rien.

          Ca n'empeche bien sur pas de booter sur un Live CD et tout acceder.

      • [^] # Re: Accès physique.

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

        Je parle de sélectionner une simple option accessible, par défaut à n'importe quel utilisateur, qui me fait passer en root sur la machine!

        Au moins comme ça tu le sais (maintenant).
        Car sans ça, tu penserais encore que des données locales seraient en sécurité sans ton mot de passe, ce qui est une idée très très débile. Répète-toi toujours : quand on accès physique à la machine, la sécurité est nulle.

        Si on veut accéder à tes données, si il n'y avait pas les options du boot indiquée partout, on a juste à prendre ton disque dur et le mettre sur le PC d'à côté, et c'est réglé. Windows, Mac ou Linux, tout pareil. Et c'est voulu, pour des questions de facilité de maintenance.

        Bon, après si tu es un maniaque, tu peux toujours crypter tes données, et mieux toujours avoir tes données sur un file ailleurs.
        D'ailleurs, des données sur un simple PC ne doivent pas être importantes, vu qu'il n'y a pas de backup etc... dessus. Si tu mets des données sensibles sur un disque dur de ta machine, ce n'est pas la distribution qui est le maillon faible, mais... Toi.

    • [^] # Re: Accès physique.

      Posté par  . Évalué à 3.

      Ça dépend la portée de l'accès : juste clavier/écran, ou boîte aussi. Sinon les administrateurs d'ordinateurs dans les lieux publics (ou université, ou cyber-café) seraient vraiment dans la merde.

      • [^] # Re: Accès physique.

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

        Justement, pour les cyber-cafés, j'ai vu deux écoles :
        - ceux qui posent le boîtier à côté de l'écran, donc largement accessible ;
        - ceux qui l'enferment dans un boîtier ou un caisson.

        Dans le second cas, pour la maintenance, il ne faut pas oublier les outils pour ouvrir le dit boîtier. Dans les cas, il faut tout de même être discret, même si rebooter le PC est possible.
        Pour ce dernier cas, on bloque généralement dans le BIOS, la possibilité de booter sur clés USB ou sur CD.
        Évidemment, tout cela est dissuasif car si tu as une heure devant toi, personne dans les parages, et que tu as ta visseuse électrique sous le coude, tu peux facilement faire sauter cette protection toute relative. Le premier but étant d'éviter que les clients fassent n'importe quoi pendant les horaires d'ouvertures.

  • # Pas vraiment

    Posté par  . Évalué à 6.

    Je ne vois pas vraiment de problème ici.
    Il suffit de booter sur un livecd pour modifier /etc/shadow et débloquer la machine.

    La seule solution viable pour se protéger des accès physiques à la machine est de chiffrer les partitions.

    • [^] # Re: Pas vraiment

      Posté par  . Évalué à 9.

      > La seule solution viable pour se protéger des accès physiques à la machine est de chiffrer les partitions.

      Et encore... ça ne te protège pas forcément d'un leurre...

      ... mettons que tu ne te trimballes pas le /boot sur toi (par exemple, sur une clé USB), mais qu'il est sur la machine, en clair, prêt à se faire tirer comme un lapin... et que ton initrd te demande un mot de passe pour débloquer les partitions autres que /boot...

      Maintenant, imaginons qu'une personne mal intentionnée avec un accès physique à la machine ait remplacé ton disque dur (qu'elle a emporté avec elle) par un autre contenant un initrd de même apparence, qui va te demander un mot de passe de la même manière, mais sera configurée pour dumper le mot de passe dans un fichier ou sur le réseau, et te dire que, pas de bol, quel qu'il soit, le mot de passe est bon, mais que les partitions chiffrées sont corrompues...

      ... et paf... ton disque est entre les mains de quelqu'un d'autre, et le mot de passe pour le débloquer aussi, si le fichier a été dumpé sur le réseau (en mettant ce qu'il faut dans l'initrd aussi)... ou au pire, pendant que tu es parti sur une autre machine télécharger une distro ou choper tes sauvegardes pour réinstaller, le margoulin n'a qu'à passer récupérer le passe dumpé localement...

      Alors, OK, on pourrait imaginer booter sur un autre OS, sur support externe, et vérifier le hash du /boot local avant de faire quoi que ce soit (m'enfin, à ce compte, autant mettre dès le départ le /boot sur un périph externe)...

      Mais la parano, c'est sans fin (parce que bon, après, qu'est-ce qui empêche de se méfier du matériel lui-même, outre ce qui est installé dessus ?)... et à un certain stade, protéger physiquement la machine (portes et fenêtres, voire aération, que même les pompiers ou le GIGN auraient du mal à ouvrir, pas de réseau, isolation électromagnétique, hordes barbares de mercenaires pour te protéger, ...), c'est peut-être encore ce qu'il y a de plus "direct". La sécurité, notamment en informatique, c'est une notion relative, pas absolue.

      • [^] # Re: Pas vraiment

        Posté par  . Évalué à 10.

        Ou même plus simple :

        On prend ton chat en otage et on te force à donner ton mot de passe...!

        pfff, ils ont pas pensé à ça chez Ubuntu !!

        • [^] # Re: Pas vraiment

          Posté par  . Évalué à 4.

          > On prend ton chat en otage

          C'est pour ça que je les dresse au combat !

          ... bon, d'accord : c'est aussi parce que, vu qu'ils ne sauraient s'imaginer comme autre chose que des collocs, il serait intolérable qu'en échange de la bouffe et cie, ils soient incapables de m'amuser. Non, mais...

  • # C'est fait pour !

    Posté par  . Évalué à 3.

    Et à ton avis, il sert à quoi le "recovery mode" ?
    Ben justement, il sert exactement à ça: récupérer une machine dont on a bêtement perdu le mot de passe, ou dont le fichier /etc/passw est mort, etc.
    C'est tout de même bien pratique sur une distribution destinée entre autres à Madame Michu.

    • [^] # Re: C'est fait pour !

      Posté par  . Évalué à 1.

      A noter que sous Ubuntu il ne demande pas de mot de passe parce qu'il n'y a pas de mot de passe root. Si mes souvenirs sont bon, quand tu définis un mot de passe root, il te le demande pour acceder au shell en recovery.

      Mais comme cela a déjà été dit, faut aller très loin pour avoir une sécurité correcte avec un accès physique.

      • [^] # Re: C'est fait pour !

        Posté par  . Évalué à 6.


        Mais comme cela a déjà été dit, faut aller très loin pour avoir une sécurité correcte avec un accès physique.


        pas trop loin non plus, sinon on va se faire voler le pc, non ?





        ======> [ ]

      • [^] # Re: C'est fait pour !

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

        Sur mandriva on peux définir, en plus des mdp usuels :
        un mdp grub (empéchant le passage d' option noyaux)
        et le mdp sur init 1 (ou pas)

        • [^] # Re: C'est fait pour !

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

          (complément)
          sur mandriva on peux définir [ie : pour madame michue : mode graphique 3 cliquous c' est prêt]

        • [^] # Re: C'est fait pour !

          Posté par  . Évalué à 1.

          Où ça? J'ai jamais trouvé ça dans le MCC!

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

          • [^] # Re: C'est fait pour !

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

            pour le mdp grub, on peux le faire dès l' installation. (tout comme une RedHat)
            pour protéger l' init 1, c' est dans draksec ;)
            et regarde le nouveau "control parental", il y aussi des choses très sympa à faire.
            aussi le nouvel onglet de draksec, permettant de facilement dire "telle chose tel mdp" ...
            Mandriva c' est très sympa de ce côté là. Rendre Linux vraiment user-friendly.



            PAM permet ensuite de faire des choses surprenantes, par la suite.

            exemples courants :
            _ n' autoriser su que pour le tel groupe (wheel souvent)
            _ définir donc limiter le nombre de connections autorisées pour tel et tel utilisateur. (connections locales. distantes)
            _ définir les ressources maximales possibles (quantité de mémoire vive par exemple) pour tel utilisateur.
            _ définir les priorités pour tel utilisateur
            _ définir les heures d' ouverture de connections de tel utilisateur.
            Reportez vous à la documentation de PAM chez SUN ou chez votre distributeur GNU/Linux ;)


            Pour ceux souhaitant aller encore plus loin, il y a la nouvelle fonction CGROUP intégrée aux derniers noyaux. Là on peux carrément dire "tel Cgroup [ie : pas un groupe unix] à droit d' utiliser tant de % de tel processeur... effroyable ;) Long, très long à configurer, mais effroyable...

            Cdlt

  • # Beaucoup de bruit pour rien

    Posté par  . Évalué à -1.

    Effectivement j'entends beaucoup de truc qui son un petit peu faux !
    Le problème c'est juste qu'il n'a pas mis les mots de passe là ou il fallais :)

    Sans modifier l'intégritè de l'ordinateur :
    1) Mettre init=/bin/bash dans grub ou lilo au démarrage.
    Effectivement c'est possible de faire cette manip puis ensuite de changer le mot de passe root.
    Mais pour contrer cette attaque il suffit de configurer votre boot loader en mode sécure:
    GRUB: http://www.linux-france.org/article/sys/chargeurs/ix86/grub/(...)
    LILO: man 5 lilo.conf search password option

    2) Un formatage n'efface pas toutes les informations du disque dur
    Et ben ça dépend !
    On peut faire un formatage qui efface uniquement les donnèes utilisèes pour connaitre les informations comme par example. i.e: Effacer la table de i-nodes en ext2/3/4

    3) Utiliser un live CD
    Il suffit de mettre un mot de passe dans le BIOS

    4) Attaque sur la RAM
    impossible

    En modifiant l'intégritè de l'ordinateur :
    1) Utiliser un live CD est possible. On pousse les bons boutons sur la carte mère et hop on reset le BIOS et on peut lancer un live cd

    2) Attaque sur la RAM :
    Si la ram est assez persistante. Là, je n'en sais pas plus

    3)Disque dur cryptè
    Surement d'autre moyen pour le décryptage que l'attaque par la ram


    Voilà :)

    • [^] # Re: Beaucoup de bruit pour rien

      Posté par  . Évalué à 3.

      4) Attaque sur la RAM
      impossible

      Euh, si le BIOS/l'OS n'initialise pas la RAM à zéro partout lors du démarrage, il est tout à fait possible de récupérer les données rémanentes juste après un redémarrage. En effet, dès que l'ordinateur est redémarré sans perte d'alimentation pendant trop longtemps, la RAM est maintenue sous tension quasiment tout le temps, son contenu est donc presque intégralement resté (les cellules n'ayant en général pas eu le temps de se vider, et n'ayant pas été vidées logiciellement).

      Un simple programme C qui alloue autant de mémoire qu'il y a de RAM, puis qui lit les données allouées sans les avoir initialisées récupèrera quasiment intégralement l'état de la mémoire avant le redémarrage (un peu moins, à cause de l'OS qui se sera installé quelque part et qui aura donc écrasé une partie de la mémoire initiale, et encore un peu moins parce que fatalement le programme sera swappé, on risque de lire des données du swap et non pas de la RAM précédente).

      • [^] # Re: Beaucoup de bruit pour rien

        Posté par  . Évalué à 1.

        Oui effectivement tu peut lancer un programme pour faire ce que tu dis.
        Mais le hic est que le 4) fait partis de la partie sans modification de l'intégrite physique de la machine.
        Comment fait tu pour pouvoir lancer ton programme au demarrage sachant que tu ne eux modifier la commande de démarrage car grub et lilo on était configurè avec un mot de passe.

        Que le BIOS, lui aussi sous mot de passe ne permet pas de booter sur un lecteur CD.

        Je te laisse répondre :)

        • [^] # Re: Beaucoup de bruit pour rien

          Posté par  . Évalué à 1.

          En fait je ne considère pas qu'on doive le lancer au démarrage, il suffit d'avoir (un compilateur, encore que... et) un compte ouvert sous la main après redémarrage (même avec des droits restreints, si l'exécution de programmes est possible, c'est bon !)

          Si la session est totalement bloquée, évidemment c'est plus difficile :-) un redémarrage d'un PC bien configuré ne donnera pas d'accès à la machine.

          • [^] # Re: Beaucoup de bruit pour rien

            Posté par  . Évalué à 1.

            En fait je ne considère pas qu'on doive le lancer au démarrage, il suffit d'avoir (un compilateur, encore que... et) un compte ouvert sous la main après redémarrage (même avec des droits restreints, si l'exécution de programmes est possible, c'est bon !)

            Comment tu recuperes les données dans la RAM sans compte root ?

            • [^] # Re: Beaucoup de bruit pour rien

              Posté par  . Évalué à 2.

              Comme je l'ai dit plus haut, avec un simple programme après redémarrage (brutal idéalement, pour conserver au maximum les programmes dans l'état dans lequel ils étaient). Le principe est d'allouer beaucoup de mémoire, sans l'initialiser, et de lire les valeurs obtenues.
              Évidemment cela ne marche que s'il n'y a pas de réinitialisation de la RAM ni par l'OS, ni par le BIOS, et on ne peut pas tout récupérer (notamment la mémoire utilisée par l'OS qui tourne après ce redémarrage).

              Mais ça donne une méthode "du pauvre" qui vaut ce qu'elle vaut. Mais moins l'OS occupe de mémoire, plus on a de chance de trouver des informations intéressantes.

              • [^] # Re: Beaucoup de bruit pour rien

                Posté par  . Évalué à 1.

                En fait pour préciser un peu l'environnement, on ne récupère pas l'état de la mémoire des programmes qui tournent actuellement sur la machine, ce qui nécessiterait évidemment d'être root.

                On récupère un instantané d'une grande partie de la mémoire de l'ensemble des processus qui tournaient sur l'ordinateur juste avant le redémarrage.

                Pour éviter la mise à zéro de la mémoire par le BIOS, il faut activer les options "démarrage rapide" ou bien "ne pas vérifier la mémoire au démarrage".

                • [^] # Re: Beaucoup de bruit pour rien

                  Posté par  . Évalué à 2.

                  On récupère un instantané d'une grande partie de la mémoire de l'ensemble des processus qui tournaient sur l'ordinateur juste avant le redémarrage.

                  C'est possible uniquement en root, toutes les allocations de processus se font sur des pages remplies de 0 (dans le kernel, la libc peut réutiliser des allocations au sein d'un même processus).
                  Ce n'est pas possible d'obtenir de la mémoire non-initialisé du kernel (ce serait une "information leak" très grave).

                  Tu peux regarder le code, par exemple do_brk() (pour faire grossir le tas), appelle bien kmem_cache_zalloc(), de même pour mmap() (l'autre façon de faire grossir le tas).
                  http://lxr.linux.no/linux+v2.6.26.3/mm/mmap.c

                  La seule façon d'obtenir l'ancien état de la mémoire est soit d'être root (et de lire /dev/mem) soit de modifier l'OS (ce qu'il vaut mieux faire pour minimiser la réecriture de la mémoire).

                  • [^] # Re: Beaucoup de bruit pour rien

                    Posté par  . Évalué à 4.

                    Mea maxima culpa, tu as raison, moinssez-moi.

                    Résultat d'une confusion liée à la fatigue et m'ayant fait mélanger le fait qu'en C, il faut initialiser ses variables, et qu'une récente faille de sécurité du noyau Linux avait, justement, laissé la possibilité à un programme non privilégié d'accéder en lecture à certaines pages de la mémoire d'autres processus/de processus terminés.

    • [^] # Re: Beaucoup de bruit pour rien

      Posté par  . Évalué à 6.

      Il y a de l'écho ici.

  • # man grub

    Posté par  . Évalué à 5.

    Autrefois j'installais des Ubuntu par paquet dans des centres informatiques, je crois que je m'y réfléchirais à 2 fois maintenant...

    L'avantage d'un Linux sur un Windows, c'est que tu n'es pas du tout obligé de t'en tenir au comportement par défaut du système. Si tu ne veux pas que les utilisateurs puisse passer en recovery mode, tu vires une ligne dans le menu de démarrage de grub (/boot/grub/menu.lst).

    Si tu veux que tes admins puissent quand même accéder à ces menus et/ou changer les options de démarrage, tu colles un mot de passe aux entrées du menu du à protéger, et c'est une ligne à rajouter :

    http://chara.epfl.ch/~fsalvi/docs/grub/howto-fr/grub-howto-1(...)

    Voila. Avec les quelques mots que tu trouveras dans cette page, tu pourras d'ores et déjà protéger rétro-activement toutes les distrib' que tu as déjà installées et, si ça se trouve, tu pourras p'têt même le faire sans quitter ton bureau. C'est pas génial, çà ? :-)

    • [^] # Re: man grub

      Posté par  . Évalué à 1.


      L'avantage d'un Linux sur un Windows,


      Mouais, les avantages que tu cites, je suis sur qu'un windowsien trouvera
      aussi vite comment faire les mêmes choses...

      • [^] # Re: man grub

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

        Tu as donc une demi-journée pour nous trouver cela.

        • [^] # Re: man grub

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

          Non, un windowsien a une demi-journée pour trouver ça. Il n'a pas prétendu être lui-même un windowsien.
          Par contre si pBpG est dans le coin, il est sûrement plus pertinent de lui poser la question.

          • [^] # Re: man grub

            Posté par  . Évalué à 3.

            C'est clair...

            Moi windows... je suis tripote ce que je peux, j'administre de temps
            à autre, ça va pas plus loin.

            Mais à chaque fois que je pense :
            "ça sous un Unix digne de ce nom, je te le fais en trois commande alors
            que sous windows, c'est trouve ça lourd et chiant."

            J'ai un collègue expert (réellement, pas le kéké de base) en Microsofterie
            qui se dépatouille en trois clic/deux commande.


            Donc maintenant, avant de dire windows sais pas faire ci ou ça, je tourne
            mon doigt sept fois autour de la touche entré !

          • [^] # Re: man grub

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

            Ce n'est pas une excuse.
            Cela signifie que ces options de sécurité ne sont pas accessible au commun des mortels, que ce soit sous Linux comme sous Windows.

        • [^] # Re: man grub

          Posté par  . Évalué à 3.

          Le temps de l'installation windows en fait.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

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