Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites". Attention, le forum rencontre actuellement quelques difficultés. En cas d'erreur 502, il ne faut pas re-valider l'envoi d'un message ou l'ouverture d'une discussion, au risque de créer un doublon.

La section divers se réorganise ! De nouvelles sous-sections à venir. (plus d'infos + donner son avis)

nombre réponses : 25

#0 Re : -1 »  Nettoyage dans les noyaux (kernel) » Le 12/09/2014, à 09:51

Hoper
Réponses : 506

Pas de soucis smile Merci d'avoir pris le temps de laisser un petit mot wink

#1 Re : -1 »  Nettoyage dans les noyaux (kernel) » Le 03/10/2014, à 08:47

Hoper
Réponses : 506

Pour info, une nouvelle version du paquet est disponible. Mais c'est uniquement le paquet qui à changé (ajout d'un "copyright" et modification des droits pour que le paquet soit un peu plus "propre"). Le script lui n'a pas été modifé, il reste donc en version 3.6

Cela devrait corriger les problèmes d'installation, car la logitheque n'aimait pas trop le paquet précédent.

#2 Re : -1 »  Nettoyage dans les noyaux (kernel) » Le 14/11/2014, à 20:49

Hoper
Réponses : 506

Bonjour,

Merci pour ton retour.

Non, je n'ai jamais soumis ce paquet pour qu'il soit intégré.
D’abord parce que je ne suis pas certain que son niveau de
qualité (que ce soit l'application ou la packaging) soit suffisant,
(par exemple il n'est pas localisé)
ensuite parce que le processus est un peu compliqué.

Pour l’icône, tu as raison. J'ai pris une icône qui existait déjà
avec un dessin assez générique. Il est bien évidement que si on me
propose une icone spécifique, j'essayerai de l'intégrer avec joie.
(Mais moi, le graphique, c'est vraiment pas mon truc).

#3 Re : -1 »  Nettoyage dans les noyaux (kernel) » Le 14/11/2014, à 22:29

Hoper
Réponses : 506

Il est super le balai ! J'adore smile Mais rien sur le site n'indique que ce logo est libre sad

#4 Re : -1 »  Nettoyage dans les noyaux (kernel) » Le 20/11/2014, à 01:52

Hoper
Réponses : 506

Très joli smile

Plus qu'a voir comment intégrer ça...
Mais merci, je rajoute ça à ma todo list.

#5 Re : -1 »  Nettoyage dans les noyaux (kernel) » Le 01/12/2014, à 13:01

Hoper
Réponses : 506

Oups non... J'ignorai totalement que ce n'était pas (plus) installé par défaut. Je vais faire les modifications nécessaires (et me renseigner sur pkexec que je ne connais pas).

Merci a vous deux pour la remonté d'infos smile

#6 Re : -1 »  Nettoyage dans les noyaux (kernel) » Le 01/12/2014, à 15:15

Hoper
Réponses : 506

Il faudrait voir si gksu à lui même beaucoup de dépendances ou pas (entraîne t-il l'installation de toute la suite gnome par exemple ou pas)

Je regarderai ça quand j'aurai un peu de temps... Mais c'est clairement assez urgent comme truc hmm

#7 Re : -1 »  Nettoyage dans les noyaux (kernel) » Le 02/12/2014, à 15:29

Hoper
Réponses : 506

Babdu89 : Merci pour les compliments smile

Il faut vraiment que je fasse les modifications.
Ajout de la dépendance plus ajout du logo...

#8 Re : -1 »  Nettoyage dans les noyaux (kernel) » Le 03/12/2014, à 10:59

Hoper
Réponses : 506

Voila ! Nouvelle version 3.7.

L'icone est donc joli, et une dépendance à gnome-sudo à été ajoutée.
(gnome-sudo et pas gksu, car gksu "fourni" gnome-sudo, et ce .deb devrait donc rester compatible avec les très vielles versions d'ubuntu).

Merci pour les précédents retours, qui me permetent de maintenant ce script au fur et à mesure des changements apportés par canonical.

#9 Re : -1 »  Nettoyage dans les noyaux (kernel) » Le 18/12/2014, à 20:42

Hoper
Réponses : 506

Houla... pas normal du tout ça...
Pourrai tu stp me copier le résultat de la commande suivante :

dpkg -l | grep linux

J'aimerai bien savoir ou il a trouvé un signe '+'.
Pendant qu'on y est, pourrai tu aussi vérifier l'intégrité du script
avec la commande :

md5sum /usr/bin/kclean

Merci !

#10 Re : -1 »  Nettoyage dans les noyaux (kernel) » Hier à 10:28

Hoper
Réponses : 506

Bonjour,

Il doit y avoir un problème dans ton script, car le checksum
ne correspond pas. Voici ce que j'ai chez moi :

md5sum /usr/bin/kclean
1f516bb9f4d2398bb6e7cb26abfab9bb  /usr/bin/kclean

Ce qui est bien la valeur que j'avais indiqué sur la page kclean.
http://hoper.dnsalias.net/tdc/index.php?pages/kclean

Je te tout supprimer, et ré-installer

sudo apt-get remove --purge kclean

et ré-install.

Ensuite, relance md5sum et vérifie que tu as bien la même valeur que moi.

#11 Re : -1 »  Nettoyage dans les noyaux (kernel) » Hier à 11:14

Hoper
Réponses : 506

Je n'ai pas conservé l'historique des md5 des versions. Quelle est ta version de kclean ? (commande kclean -v). Globalement mieux vaut être à jour mais je ne pense pas que le soucis qu'il ai rencontré vienne de la sad

#12 Re : -1 »  Nettoyage dans les noyaux (kernel) » Hier à 11:40

Hoper
Réponses : 506

alca94 : Merci pour l'info. Tu n'a pas besoin de mettre à jour. Mais du coup cela ne résoudra pas le problème de Gaara. Son soucis vient d'ailleurs sad

Gaara : Que donne :

sudo apt-get remove linux-image-3.16.0-23-generic

J'ai l'impression que ton soucis vient de la...
Ta base de donnée apt semble corrompue d'une façon ou d'une autre.
Tu peux aussi esayer un :

sudo apt-gett install -f

#13 Re : -1 »  Nettoyage dans les noyaux (kernel) » Hier à 11:49

Hoper
Réponses : 506

En ligne de commande oui, en copiant tout ce que ça te sort.
Pour le moment, je t'avoue que je comprend pas trop ce qui se passe sad

#14 Re : -1 »  Nettoyage dans les noyaux (kernel) » Hier à 12:07

Hoper
Réponses : 506

Non rien à voir, pas de soucis pour le apt-get clean.
Pas facile de comprendre ce qui se passe sans être sur la machine sad
Il y a un truc qu'on peut faire encore pour essayer d'y voir plus clair.

Il faudrait que tu édite le script kclean :

sudo gedit /usr/bin/kclean

(ou un truc du genre).
A la ligne 25, tu dois avoir un truc comme ça :
rm -f /tmp/clean_kernel.tmp
Commente cette ligne en ajoutant un # au debut.

Puis relance le script.
Ensuite, copie ici le contenu du fichier "/tmp/clean_kernel.tmp"
par exemple en faisant :

cat /tmp/clean_kernel.tmp

#15 Re : -1 »  Nettoyage dans les noyaux (kernel) » Hier à 13:36

Hoper
Réponses : 506

Ok, que donne :

dpkg -p linux-image-3.16.0-24-generic

#16 Re : -1 »  Nettoyage dans les noyaux (kernel) » Hier à 16:18

Hoper
Réponses : 506

Le probleme vient de la mais pourquoi ? Que s'est il passé sur ta machine ? La comme ca je sais pas. Il faut que je reflechisse un peu (et que je trouve du temps car la c pas top)

#17 Re : -1 »  Nettoyage dans les noyaux (kernel) » Hier à 16:42

Hoper
Réponses : 506

Essaye la meme commande (dpkg -p) avecd'autres paquets n'ayant rien a voir avec le noyau pour voir...

#18 Re : -1 »  Nettoyage dans les noyaux (kernel) » Hier à 17:15

Hoper
Réponses : 506

Bravo ! smile

Mais alors... pourquoi -s à fonctionné la ou -p n'a pas fonctionné !?
Devrais-je remplacer -p par -s ? et pourquoi ?
Cette histoire me "perplexifie" grandement...

#19 Re : -1 »  Partition swap » Le 12/12/2014, à 08:35

Hoper
Réponses : 9

Bonjour,

Pas de soucis pour :
* Créer la partition de swap à n'importe quel endroit
* Ne pas utiliser de swap du tout
* Ne pas dédié une partition pour cela mais plutôt utiliser un fichier
  placé à l'endroit de ton choix.

Attention à une chose : Sans swap, tu ne pourra pas utiliser la fonction d'hibernation (que je déconseille d'utiliser de toute façon).

#20 Re : -1 »  Partition swap » Le 12/12/2014, à 09:38

Hoper
Réponses : 9

Effectivement on dirait du gros n'importe quoi cette histoire de 60%. D'ailleurs l'article se contredit :

"C'est simple. Pour qu'un SSD vive longtemps.......il ne faut pas l'utiliser ! Sérieusement, il faut lui éviter au maximum les écritures inutiles qui usent les puces mémoires."

Et la oui, je suis d'accord, il faut écrire (et surtout ré-écrire) le moins possible. Or, si on fait "tourner" les informations sur les différentes puces, forcement on augmente le nombre d'écritures... Donc on diminue la durée de vie du disque !

#21 Re : -1 »  Demande d'explications sur des attaques potentielles » Le 24/11/2014, à 02:43

Hoper
Réponses : 6

Yop,

Déjà, il faut bien comprendre le contexte.

Quand tu met en place une sécurité (quel qu'elle soit), tu doit commencer par définir contre quelles menaces tu essaye de te protéger. Pour cela, tu imagine ce que l'attaquant sera capable de faire. (Tu définis un "modèle d'attaque").

A partir de la, tu pourra réfléchir et voir si la sécurité que tu as mise en place est bonne ou pas, par rapport aux capacités supposés de l'attaquant.

Par exemple, quand on fais de la sécurité réseau, on part généralement du principe que l'attaquant sera capable :

* D'écouter tous les paquets qui transitent
* De forger et d'envoyer des paquets sur le réseau
  (paquets qui pourraient etre constitués tout ou parti de ce qu'il a précédemment écouté)
* De se faire passer pour une autre machine
* D'intercepter des paquets envoyés à une autre machine (et donc de faire en sorte que la vraie machine de destination ne les reçoivent jamais)
* et sûrement d'autre trucs que j’oublie.

C'est un modèle théorique. On ne dit pas comment il peut se faire passer pour une autre machine ou comment il pourrait bloquer des paquets réseaux. Et en pratique, ce serait certainement très compliqué à réaliser. Mais on suppose qu'il en serait capable, et on définit des protocoles (ssh etc) qui doivent rester robustes à un attaquant ayant toutes ses possibilités.

Ici c'est la même chose. On ne dit pas comment l'attaquant pourrait faire ce qui est indiqué. On suppose simplement qu'il en serait capable.

Pour moi, dans le cas du chiffrement des disques, il faut simplement partir du principe que l'attaquant est root. Il peut donc faire n'importe quoi sur le disque (lire ou écrire n'importe quel secteur, demander le chiffrement ou le déchiffrement de n'importe quel bloc etc). Mais bien sur, il y a une seule chose qu'il ne connaît pas, c'est la bonne clef, celle qui à été utilisée pour le chiffrement. Donc, sans connaître cette clef, il faut s'interroger sur ce qu'il pourrait mettre en place pour la trouver (en examinant les blocs avant ou après chiffrement etc).

Avec un bon algorithme de chiffrement, même si tu es root sur la machine, jamais tu ne pourra déchiffrer les infos. C'est ce que cette page doit vouloir indiquer de façon un peu compliqué je trouve mais bon...

#22 Re : -1 »  Demande d'explications sur des attaques potentielles » Le 24/11/2014, à 23:33

Hoper
Réponses : 6

Ne faut-il donc pas se garder de chiffrer son système ou, si on veut vraiment lui compliquer la tâche, de le chiffrer avec une clé différente de celle qui sert à chiffrer les données, de façon à lui faire perdre son temps sur une fausse piste ?

Je pense qu'il faut distinguer deux scénarios différents.

1) Une personne à "hacker" ton ordi, et est connectée (root) sur ton ordinateur pendant que tu l'utilise.

Dans ce cas la, tot ou tard, il réussira à avoir la clef, probablement en installant un keylogger et en attendant que tu déchiffre toi même le disque. Supposons que tu n'accède que très rarement aux données chiffrés, alors le fait que le système soit chiffré (avec la même clef) pourrait l'avantager. Pas pour la raison que tu indique, mais parce que l'accès aux fichiers systèmes et alors possible (l'ordinateur fonctionne) et la clef de déchiffrement se trouve alors forcément quelque part en mémoire. Il me semble qu'il existe des attaques pour essayer de la retrouver. Ca doit pas être simple, mais d'un point de vue purement théorique, c'est forcément possible.

2) L'attaque se fait "off line" (la personne à volé ton disque ou ton pc etc). Dans ce cas, chiffrer le système est une bonne idée, que ce soit avec la même clef ou pas.

De toute façon, il faut bien voir que c'est l'ensemble du FS qui est chiffré, pas chaque fichier séparément. Donc le fait de savoir qu'il existe quelque part sur le disque un fichier dont le contenu est connu d'avance (/etc/inittab ou ce genre de chose) ne va pas beaucoup l'aider. Pour trouver la localisation de ce fichier il faudrait commencer par déchiffrer les blocs d'inodes etc...

Par contre, il est fort probable que si le système n'est pas chiffré, alors il y aura des informations à récupérer dedans. C'est fou le nombre de trucs qu'on retrouve en creusant un peu, en fouillant les "poubelles", les logs, les vignettes (prévisualisation), les préférences etc. Globalement tout ce qui n'est pas automatiquement considéré comme "fichier perso", mais qui peut révéler énormément d'infos.

Globalement, sous linux, je conseille, par ordre de priorité :

1) De faire des sauvegardes de ses données
2) De chiffrer ses données, ainsi que les sauvegardes
3) De chiffrer le système, au moins /var

Le tout en utilisant des clef et des ciphers correctes évidement.

Voila, je ne sais pas exactement ce que l'auteur de la page wikipedia à voulu dire (il y a des sections qui me semblent bizarres aussi). Je me suis contenté de te dire comment moi je l'interpréterai smile

#23 Re : -1 »  Demande d'explications sur des attaques potentielles » Le 01/12/2014, à 13:05

Hoper
Réponses : 6

Titouan :

Je ne vois pas l’intérêt de lier un disque à la carte mère.
Soit tu fais la même chose avec tes sauvegardes, et le jour ou ta carte mère lâche tu as tout perdu. Soit tu chiffre tes sauvegardes sans TPM, auquel cas le chiffrement avec TPM ne sert plus à rien (on part toujours du principe que l'attaquant attaque le maillon le plus faible).

Ce qui d'ailleurs sera bien le cas, partir avec un disque externe sera bien plus simple que d'embarquer toute la tour.

#24 Re : -1 »  MAJ impossible disque faussement plein » Le 03/10/2014, à 08:45

Hoper
Réponses : 79

Yop. Merci à Tiramiseb de m'avoir signalé le soucis dans le paquet kclean.
Je viens de réparer cette régression (car les droits étaient bons dans les versions précédentes). J'en ai proffité pour ajouter un copyright etc.

Pour lintian, il n'y a plus que l'abence de manpage qui pose problème mais c'est un warning, pas une erreure, cela devrait donc s'installer quand même.

Pour la manpage, on verra si je suis motivé un jour mais la...