CLIP OS – Les versions Nightly sont maintenant disponibles !

Les versions nightly de CLIP OS sont maintenant disponibles. Vous pouvez télécharger des paquets pré-compilés, des SDK et des images QEMU instrumentées depuis files.clip-os.org.
Sachez que ces paquets et images QEMU sont instrumentés, ce qui signifie qu’ils permettent un accès root complet sans mot de passe sur le système.
Veuillez noter que les fichiers sont fournis TELS QUELS à des fins d’ESSAI SEULEMENT et NE DOIVENT PAS être utilisés dans un CONTEXTE DE PRODUCTION.

Pour essayer rapidement d’exécuter le système CLIP OS avec QEMU, vous pouvez utiliser les commandes suivantes :

# Installer les dépendances pour les commandes nécessaires
# apt install jq zstd

# Choisir la dernière version construite avec succès provenant de pipelines
$ BUILD="$(curl https://gitlab.com/api/v4/projects/14752889/pipelines/latest | jq '.id')"

# Récupérer l’image QEMU
$ wget https://files.clip-os.org/$BUILD/qemu.tar.zst

# Extraire et entrer dans le répertoire
$ tar xf qemu.tar.zst && cd clipos_*_qemu

# Lire le fichier README (pour obtenir la pass-phrase de la partition chiffrée par exemple ^^)
$ cat README.md

# Démarrer CLIP OS avec QEMU
$ ./qemu.sh

Vous pouvez vous connecter en tant que root sans mot de passe. Amusez-vous bien !

Source: discuss.clip-os.org

LineageOS 14.1 pour le ZTE Open C / Kis 3

Une envie de Nougat ? Cela tombe bien car je viens de stabiliser LineageOS 14.1 (Android 7.1.2) pour le ZTE Open C (alias Kis 3). En effet, KonstaT nous avait offert un avant-goût de Nougat en guise d’adieu au projet en publiant une version anticipée avec pas mal de problèmes mineurs.

J’ai pour ma part optimisé les faibles ressources matérielles afin d’avoir une ROM réactive en utilisant le moins de mémoire possible. J’ai également corrigé pas mal de petits problèmes signalés par Mossroy et l’ensemble de mes magnifiques utilisateurs 🙂
C’est ainsi grâce à eux, que cette version est plus stable que ma précédente release.

Enfin, j’ai tâché de faire de mon mieux pour durcir l’ensemble, toujours avec les problèmes de ressource mais également à cause du noyau qui n’a jamais été modernisé à l’époque par le constructeur et par mozilla.

A cet effet, j’avais ajouté Grsec et j’ai notamment pu (grâce à PaX) augmenter l’ASLR :

JOURNAL DES MODIFICATIONS :
_Correction du problème du son (parfois le téléphone ne sonnait pas)
_Correction du partage de connexion wifi
_Correction du déplacement d’application sur la SD
_Ajout de F-Droid et Firefox Lite (mise à jour possible par l’utilisateur)
_Beaucoup de correction dans le noyau
_Divers changement dans la configuration de l’appareil

PROBLÈMES RESTANT A CORRIGER :
_Impossibilité d’ajouter un VPN depuis le menu paramètres
_Problème d’affichage de la mémoire de stockage restante depuis le menu paramètres

PRÉVISION POUR LA SUITE :
_LineageOS 15 voir 16 ? Peu probable et semble peu réalisable d’un point de vu technique.
_Upgrade du noyau ? Trop de travail et pas rentable pour un vieux smartphone.

REMERCIEMENT :
_KonstaT et l’équipe de LineageOS

LIEN DE TÉLÉCHARGEMENT : lineage-14.1-20181116-UNOFFICIAL-kis3_with_unofficial_grsec.zip
SOMME DE CONTRÔLE MD5: b6dd8357add9a8e401bec251d5fc2998
CODE SOURCE : disponible ici.

Vous aimez mon travail ? Un merci suffit 😉

LineageOS avec un noyau Grsec non officiel pour le ZTE Open C

Comme promis, voici une nouvelle version de ma ROM LineageOS pour le ZTE Open C.
La principale nouveauté est le port (non officiel) d’une ancienne version du patch de sécurité Grsecurity.
Le noyau étant obsolète, tout durcissement étant ainsi bon à prendre.
Veuillez notez que toute les options de grsec ne sont pas encore activées mais cela viendra 😉

JOURNAL DES MODIFICATIONS :
Activation de SCHED_AUTOGROUP (pour les performances).
Remplacement du bootanimation par un simple logo animé (plus léger).
Désactivation du démarrage automatique de debuggerd.
Ajout du patch grsec (basé initialement sur la version 2.9.1-3.4.7-201208021520).
Correction de plusieurs fonctions comme « virt_addr_valid » et « alloc_vmap_area ».
Résolution d’un problème de corruption sur slab (non fixé dans le noyau de KonstaT).
Résolution de plusieurs problèmes de stabilité de ma précédente ROM qui contenait PaX.

LIEN DE TÉLÉCHARGEMENT : lineage-13.0-20180425-UNOFFICIAL-kis3_with_unofficial_grsec.zip
SOMME DE CONTRÔLE MD5 = 0d224de872609d5146230e226da319ce
CODE SOURCE : disponible ici.

LineageOS avec PaX pour le ZTE Open C

Comme promis dans les commentaires sur mon précédent article, voici ma version récente de LineageOS ayant pour principale nouveauté l’ajout de PaX afin de durcir le noyau du ZTE Open C.

Journal des modifications :

  1. MODIFICATION CONCERNANT LINEAGEOS :
    Démarrage en « slub_debug=P slab_nomerge »
    Amélioration de l’énergie en activant le mode « NO_WIFI_STATS »
    Désactivation du DRM Widevine
    Randomisation des adresses MAC avant l’association
    Optimisation de Zygote
    Utilisation des notifications privées par défaut sur le verrouillage d’écran
    Début du marquage des applications nécessaire pour l’activation de PaX MPROTECT
    Ajout d’une ligne indiquant le statut de PaX dans le menu « Paramètres –> A propos » du téléphone.
    Désactivation de statistique et de rapport d’erreur.
  2. MODIFICATION DU NOYAU LINUX :
    Durcissement de la configuration du noyau en utilisant les recommandations du KSPP
    Ajout du patch PaX pour durcir le noyau qui en a bien besoin
    Note: L’option MPROTECT est fonctionnelle mais non activée pour ne pas casser les applications utilisant du javascript. comme le HTMLViewer, le Browser etc…
    J’ai commenté du « print » dans la couche MSM (avec la description « NO-SPAM ») pour dépolluer le dmesg.
    Quelques backports pour avoir un port fonctionnel de PaX
    Backport des Kconfig de Grsecurity
    Ajout de « android_aid.h » provenant de CopperheadOS afin d’utiliser PaX MPROTECT à l’avenir.
    Restriction sur config.gz, timer_list, timer_stats et kallsyms.
    Application d’une recommandation de Grsecurity sur user_namespace.c
    Suppression de l’avertissement « SECTION_MISMATCH » qui apparaît avec PaX
    Passage du numéro de compilation du noyau en 1337 😉
  3. PREVISION POUR LA SUITE :
    Peaufinage de mon port de PaX
    Ajout du patch Grsecurity 3.4.7 (notamment pour avoir une meilleure journalisation)
    Étudier la possibilité de passer le noyau en version 3.10
    Passage sur LineageOS 14.1 (car la version 13.0 basée sur android 6.0.1 n’est officiellement plus maintenue)
    Optimisation à faire pour économiser les faibles ressources du matériel surtout avec les versions récentes de LineageOS.
  4. LIEN DE TELECHARGEMENT : http://dl.free.fr/ke2mMtHTj
    MD5 = ee211a235828dba3495dce69f96ef543
    Source: Public-sharing

Je tiens à remercier encore une fois KonstaKANG pour la qualité de son travail laissé accessible et que j’ai pu récupérer comme base pour le ZTE Open C.
Je rappel également que c’est un port non-officiel de recherche maintenu seul de mon coté et par conséquent qu’il s’adresse aux utilisateurs expérimentés.

Ma version de LineageOS 13 pour le ZTE Open C

Bonjour à tous,

J’avais acheté en 2014 un ZTE Open C sous Firefox OS mais hélas ce système d’exploitation mobile libre n’a pas eu le succès escompté. Je me suis alors rabattu sur CyanogenMod puis LineageOS via l’excellent port non-officiel de KonstaT.

Ne voyant pas l’intérêt de changer mon téléphone tant qu’il fonctionne, j’ai donc mis à jour la rom de KonstaT afin d’avoir le dernier correctif de sécurité Android disponible permettant notamment de corriger la vulnérabilité BlueBorne et de commencer à durcir le noyau linux utilisé. Si j’ai utilisé va version 13 (Android 6.0.1) de LineageOS et non pas la 14.1 (Android 7.1.1) c’est car elle offre de meilleures performances.

Voici les modifications que j’ai effectuées :

  1. Application des recommandations KSPP sur la configuration du noyau
  2. Restriction de l’accès à /proc/<PID>/environ jusqu’à ce qu’il soit prêt
  3. Réduction de la surface d’attaque sur user_namespace par PaX/Grsecurity
  4. Désactivation de l’horodatage TCP
  5. Restriction d’accès sur /proc/config.gz et /proc/kallsyms
  6. Ajout de DENYUSB (port minimal de grsecurity)
  7. Ajout de DEVICE_SIDECHANNEL (provenant également de grsecurity)
  8. Ajout de GRKERNSEC_PROC_IPADDR (qui créé /proc/<pid>/ipaddr)
  9. Modification du driver PRIMA pour tester par la suite de générer une adresse MAC aléatoire sur cette carte wifi.

Idéalement, il faudrait rajouter l’émulation PXN/PAN et la fonction hardened usercopy pour sécuriser d’avantage la version obsolète du noyau Linux utilisé (version 3.4) ou mieux encore inclure PaX/Grsecurity. Sans plus tarder, voici :

Ma ROM personnalisée (Somme de contrôle MD5=71d4b469911b24ac49b56b7ac166df3d)
lineage-13.0-20171005-UNOFFICIAL-kis3.zip

Et le patch regroupant mes modifications :
LOÏC-UNOFFICIAL-kis3.patch

Si vous avez des questions concernant l’installation, veuillez-vous référer au site konstakang.com où tout est bien expliqué.

Matériel pour GNU/Linux

RYF

Suite à une demande récente dans commentaire et à l’approche des fêtes de fin d’année (et oui que le temps passe vite…) beaucoup seront tentés de faire des achats numériques. En tant que Linuxien et fervent défenseur des logiciels libres, voici quelques liens pour vous aider à vous décider.

Matériel libre certifier par la FSF:
https://www.fsf.org/resources/hw/endorsement/respects-your-freedom
https://h-node.org/hardware/catalogue/en

Carte mère et PC portable pouvant être exorciser (totalement libéré):
http://www.libreboot.org/docs/hcl/
http://www.coreboot.org/Supported_Motherboards
https://www.fsf.org/resources/hw/systems/

Matériel embarqué (routeur principalement):
https://wiki.openwrt.org/toh/start

Matériel testé sous GNU/Linux:
https://www.debian.org/distrib/pre-installed#fr
https://www.ubuntu-fr.org/revendeurs
http://doc.ubuntu-fr.org/materiel_assembleurs_en_ligne
http://doc.ubuntu-fr.org/ordinateur_vendu_avec_ubuntu
http://www.dell.com/learn/fr/fr/frbsdt1/campaigns/dell-linux-ubuntu-en?c=fr&l=fr&s=bsd
https://wiki.archlinux.org/index.php/HCL/Laptops

Identifier les bons constructeurs:
http://bons-constructeurs-ordinateurs.info/#bons-optionnalite

D’autres liens à me faire connaître? N’hésitez pas à me laisser un commentaire ! 😉

Patch Linux pour changer son adresse MAC aléatoirement

MAC-freebox

Il existe plusieurs façons de changer son adresse MAC sous GNU/Linux (macchanger étant la méthode la plus connue) mais l’avantage de ce qui va suivre c’est que cela se passera directement au niveau du noyau Linux ce qui a pour avantage d’être particulièrement efficace et sûr. Alors certes il faut compiler son petit noyau mais bon nous sommes tous des geeks barbus, non?

Brad nous a sorti un petit patch (hack) sympathique pour changer aléatoirement l’adresse MAC d’une interface réseau dès que celle-ci est activée 🙂
Ainsi à chaque démarrage de l’ordinateur, les adresses MAC changent de manière aléatoire tout comme elles changeront également à chaque redémarrage du service réseau.
Pour information, le patch ci-dessous n’est pas intégré dans grsec car ce n’est pas le but visé par le projet.

Voici le code qui va bien du path « random_mac.diff » :

diff --git a/net/core/dev.c b/net/core/dev.c
index 19d9b66..9a16733 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4823,6 +4823,24 @@ int dev_change_flags(struct net_device *dev, unsigned flags)
rtmsg_ifinfo(RTM_NEWLINK, dev, changes);

__dev_notify_flags(dev, old_flags);
+
+ if ((changes & IFF_UP) && !(old_flags & IFF_UP)) {
+ /* randomize MAC whenever interface is brought up */
+ struct sockaddr sa;
+ unsigned int mac4;
+ unsigned short mac2;
+
+ mac4 = prandom_u32();
+ mac2 = prandom_u32();
+ memcpy(sa.sa_data, &mac4, sizeof(mac4));
+ memcpy((char *)sa.sa_data + sizeof(mac4), &mac2, sizeof(mac2));
+ if (!is_valid_ether_addr(sa.sa_data))
+ sa.sa_data[5] = 1;
+ sa.sa_data[0] &= 0xFC;
+ sa.sa_family = dev->type;
+ dev_set_mac_address(dev, &sa);
+ }
+
return ret;
}
EXPORT_SYMBOL(dev_change_flags);
@@ -4991,7 +5009,8 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
return dev_set_mtu(dev, ifr->ifr_mtu);

case SIOCSIFHWADDR:
– return dev_set_mac_address(dev, &ifr->ifr_hwaddr);
+ /* ignore userland MAC changes */
+ return 0;

case SIOCSIFHWBROADCAST:
if (ifr->ifr_hwaddr.sa_family != dev->type)

Pour les noyaux égals ou supérieurs à la version 3.15, j’ai dû modifier le précédant patch pour qu’il fonctionne toujours avec les versions plus récentes:

diff --git a/net/core/dev.c b/net/core/dev.c
index a30bef1..7eb6778 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5476,6 +5476,24 @@ int dev_change_flags(struct net_device *dev, unsigned int flags)

changes = (old_flags ^ dev->flags) | (old_gflags ^ dev->gflags);
__dev_notify_flags(dev, old_flags, changes);
+
+ if ((changes & IFF_UP) && !(old_flags & IFF_UP)) {
+ /* randomize MAC whenever interface is brought up */
+ struct sockaddr sa;
+ unsigned int mac4;
+ unsigned short mac2;
+
+ mac4 = prandom_u32();
+ mac2 = prandom_u32();
+ memcpy(sa.sa_data, &mac4, sizeof(mac4));
+ memcpy((char *)sa.sa_data + sizeof(mac4), &mac2, sizeof(mac2));
+ if (!is_valid_ether_addr(sa.sa_data))
+ sa.sa_data[5] = 1;
+ sa.sa_data[0] &= 0xFC;
+ sa.sa_family = dev->type;
+ dev_set_mac_address(dev, &sa);
+ }
+
return ret;
}
EXPORT_SYMBOL(dev_change_flags);
diff –git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index cf999e0..265c2b3 100644
— a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -260,6 +260,8 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)

case SIOCSIFHWADDR:
return dev_set_mac_address(dev, &ifr->ifr_hwaddr);
+ /* ignore userland MAC changes */
+ return 0;

case SIOCSIFHWBROADCAST:
if (ifr->ifr_hwaddr.sa_family != dev->type)

Bonne compilation 😉

Libérer un BIOS/UEFI – Installation de coreboot sur l’ASRock E350M1

Coreboot_full_web

Mes chers lecteurs, bien que majorité d’entre vous utilise un système d’exploitation GNU/Linux ou *BSD, combien d’entre vous peuvent prétendre avoir un ordinateur entièrement libre et donc avoir entièrement le contrôle ?
Comme le dit si bien le site Prism-break pour éviter de participer à un programme de surveillance à votre insu vous devez avoir un accès total au code/matériel.

Au menu de cet article nous allons voir comment libérer profondément un ordinateur en remplaçant un BIOS propriétaire (un UEFI dans cet exemple) par le logiciel libre d’amorçage coreboot.
Coreboot effectue qu’un tout petit peu d’initialisation du matériel, puis exécute une logique d’amorçage supplémentaire, appelée charge utile (payload).

Avec cette séparation de l’initialisation du matériel et le démarrage logique plus tard, coreboot peut évoluer à partir des applications spécialisées qui fonctionnent directement à partir du firmware, exécuter des systèmes d’exploitations dans la mémoire flash, charger des programmes d’amorçages personnalisés, ou mettre en œuvre les normes du firmware, comme les services PC BIOS ou UEFI. Cela permet aux systèmes d’inclure uniquement les fonctions nécessaires à l’application cible, ce qui réduit la quantité de code et de l’espace flash nécessaire.

Avertissement : Bien que simplifié au maximum cet article s’adresse aux personnes expérimentées, consulter préalablement le wiki du projet voir si cette procédure est toujours d’actualité.

Ingrédients nécessaires :

_ Idéalement une distribution 100 % libre supportée par la FSF
_ Une carte mère supporté par coreboot (les modèles récents encore commercialisés sont l’ASUS F2A85-M et l’ASRock E350M1 qui sera utilisé ici pour la suite)
_ Des puces de secours
_ Un extracteur de puce
_ Optionnellement un noyau linux 100% libre (si vous voulez un noyau plus récent que celui de votre distribution).

Préparation de la recette :

Installer votre distribution.
Retirer la puce originale de la carte mère et la garder précieusement (pour la garantie notamment) et y placer l’une de vos puces.

Installer les dépendances pour la construction de coreboot :
sudo apt-get install git build-essential gnat flex bison libncurses5-dev wget zlib1g-dev gdb curl iasl

Récupérer coreboot :
git clone https://review.coreboot.org/coreboot.git
cd coreboot
git submodule update --init --checkout

Pour éviter les erreurs avec la chaine de compilation de nos distributions, taper la commande :
make crossgcc-i386 CPUS=4

Récupérer votre bios vga (depuis le wiki ou de par vous même) puis le placer à la racine du dossier coreboot (et pas ailleurs!).
cp Bios-vga-E350M1.bin coreboot/vgabios.bin

Vérifier la somme md5 du bios vga de l’Asrock E350M1 :
md5sum vgabios.bin

Vous devez absolument avoir retrouvé l’une des 2 sommes de contrôles que j’ai testé (la différence entre les 2 c’est que l’un est coupé en hexa au niveau 0000e200) :
27d5d5b9dbd69dcd9af596de59cadc2a
ou
c6489a495362c09dd591ddb5cf3c5cac

Capture-vgabios.bin - GHex

Configurer coreboot :
make menuconfig

  1. Dans « Mainboard » choisir « ASROCK » en tant que « Mainboard vendor ».
    Selectionner « E350M1 » dans « Mainboard model ».
    Vérifier que le « ROM chip size » correspond bien à la taille de vos chips, pour ma part 4096 KB (4 MB). Coreboot
  2. Dans « Generic Drivers » cocher si besoin la case « PS/2 keyboard init ».
  3. Dans « VGA BIOS » cocher la case « Add a VGA BIOS image ».
  4. Dans « Payload » vérifier que ce soit bien « SeaBIOS » qui est sélectionné.
    Seabios est la charge utile la plus compatible qui fonctionne avec Windows, Linux et BSD car elle implémente les standards des BIOS. C’est également cette charge utile qui est utilisée dans QEMU et KVM.

Passer à la compilation :
make -j4

Si tout c’est bien passé, votre bios « coreboot.rom » est disponible dans le dossier « build« .

Vérifier que votre bios vga soit bien intégré à votre rom coreboot, soit avec un éditeur de fichiers binaires genre « ghex » vous avec cette commande :
grep -a VBIOS build/coreboot.rom

La commande précédente devant vous renvoyer :
AMD Fusion Wrestler generic VBIOS

Mise au four de notre préparation :

Après la création de notre rom coreboot, nous allons utiliser l’utilitaire flashrom pour écrire sur notre puce de mémoire flash.

Pour installer Flashrom des dépôts :
sudo apt-get install flashrom

Sauvegarder le BIOS
sudo flashrom -r sauvegarde-bios.rom

Flasher le BIOS avec votre rom coreboot :
sudo flashrom -w coreboot.rom

Ou si flashrom est récent :
sudo flashrom -p internal -c "MX25L3206E/MX25L3208E" -w coreboot.rom

Enfin et uniquement si flashrom n’a pas détecté d’erreurs, vous pouvez redémarrer votre machine.

Si vous avez une erreur aller faire un tour sur l’IRC de flashrom pour demander de l’aide ou essayez de rattraper votre puce avec une version récente de flashrom provenant de branche AMD :
sudo dpkg --purge flashrom
sudo apt-get install libpci-dev zlib1g-dev pciutils
cd ~
git clone https://github.com/stefanct/flashrom.git
cd flashrom/
git checkout -b amd origin/amd
make
sudo make install

Puis re-flasher (la syntaxe peut-être différente entre la version des dépôts et la dernière version disponible) :
flashrom -p internal -c modèle-de-votre-puce -w coreboot.rom

coreboot-boot

Sur le wiki il y a également un fichier de configuration pour fancontrol afin ajuster la vitesse du ventilateur du CPU de manière dynamique. Pour cela installer fancontrol :
sudo apt-get install fancontrol

Copier le fichier de configuration au bon emplacement :
sudo cp fancontrol /etc/fancontrol

Charger le module nécessaire maintenant et redémarrer le service fancontrol :
sudo modprobe w83627ehf
sudo /etc/init.d/fancontrol restart

Puis pour charger automatiquement le module à chaque démarrage :
echo "w83627ehf" >> /etc/modules

A consommer tout de suite et sans modération. Admirer la vitesse, 2 seconde top chrono entre le démarrage et grub 😉 (et encore c’est juste l’histoire d’appuyer sur F12 pour démarrer sur un autre support mdr)

Je tiens à remercier le projet Coreboot et Flasrom pour leur travail et à remercier spécialement Alien, Rluett, Openvoid pour avoir répondu à mes questions, à GNUtoo pour son choix de carte mère, à stefanct pour sa branche git amd flasrom.

EDIT: Cet article de 2013 a été actualisé et testé en juin 2020 mais veuillez prendre en compte ceci

Test ultra-rapide du navigateur web IRON

IRON

J’ai voulu tester le navigateur web IRON conçu par SRWare éditeur de logiciels. Ce navigateur web est une version basée sur chromium offrant une meilleure confidentialité et sécurité que Google Chrome.

Cette version contrairement à Google Chrome ne contient pas de Client-ID, suggestions de recherches, pages d’erreur alternatives, rapport d’erreur, RLZ-Tracking (transmission d’informations codées à Google), mise à jour automatique, et d’URL-Tracker. Intéréssant sur le papier, j’ai décidé de tester ce dernier.

Je récupère le paquet debian ici :
http://www.srware.net/forum/viewtopic.php?f=18&t=6457

Soit pour l’occasion la version 32 bits (md5 = 145dbaa79ee26ddec4a5fd3b04b83c56).
Après l’installation, je lance l’application (avec un œil étonné vers le chemin de l’exécutable…) :
/usr/share/iron/iron

Et là ça commence bien :
/usr/share/iron/iron: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

En effet, Ubuntu 13.04 que je test sur mon netbook dispose d’une version récente de libudev, j’ai du corriger le problème via un lien symbolique :
sudo ln -s /lib/i386-linux-gnu/libudev.so.1 /lib/i386-linux-gnu/libudev.so.0

Restant particulièrement étonné du chemin de l’exécutable, je décide de regarder les permissions d’accès et là c’est le drame :
ls IRON

Un utilisateur quelconque sans droit root peut supprimer tout cela :
«/usr/share/iron/extensions»
«/usr/share/iron/content_resources.pak»
«/usr/share/iron/chrome_100_percent.pak»
«/usr/share/iron/iron»
«/usr/share/iron/chrome_remote_desktop.pak»
«/usr/share/iron/product_logo_48.png»
«/usr/share/iron/resources.pak»
«/usr/share/iron/libavcodec.so.52»
«/usr/share/iron/libavformat.so.52»
«/usr/share/iron/chrome.pak»
«/usr/share/iron/libavutil.so.50»
«/usr/share/iron/chrome-wrapper»
«/usr/share/iron/libffmpegsumo.so»

Forcement ça va beaucoup moins bien marcher après ^^ (mort de rire). C’est quand même le comble pour un soit disant « Navigateur du Futur« , « sans problème de confidentialité ni de sécurité« … J’aurai pu corriger cela rapidement via un « chmod -R 755 /usr/share/iron/ » mais j’ai décidé d’arrêter là…

IRON offre certainement une meilleure confidentialité face à google chrome d’accord, mais la différence doit être beaucoup moindre face à chromium. D’ailleurs pourquoi sortir un navigateur au lieu de créer une extension ? (qui je pense rencontrerait un plus grand succès) Dans tous les cas personnellement, je reste sous Mozilla Firefox qui offre une bonne sécurité et plus de respect de la vie privée.

Note: J’ai contacté l’éditeur en question et j’éditerais cet article si j’ai un retour.

Mon script « ClamAV Temps Réel »

J’avais besoin de créer un script que j’ai nommé « clamav-tr.sh« , celui-ci permet d’ajouter une fonction temps réel à clamav. Il scanne en temps réel le répertoire « /home » (par défaut), si un virus est trouvé, il sera déplacé en quarantaine (dans /tmp). Un fichier caché (.clamav-tr.log) sera disponible dans le dossier de l’utilisateur du script. J’utilise clamdscan (clamav-daemon) parce qu’il est beaucoup plus rapide que clamscan.

Je partage mon script, il peut être utile pour surveiller un répertoire ou des partages samba.

Pré-requis: clamav-daemon et inotify-tools.
Recommandé pour un PC de bureau: libnotify-bin.

#!/bin/bash
# Script "ClamAV Temps Réel", par HacKurx
# https://hackurx.wordpress.com
# Licence: GPL v3
# Dépendance: clamav-daemon inotify-tools
# Recommandé pour PC de bureau: libnotify-bin

DOSSIER=/home
QUARANTAINE=/tmp
LOG=$HOME/.clamav-tr.log

inotifywait -q -m -r -e create,modify,access "$DOSSIER" --format '%w%f|%e' | sed --unbuffered 's/|.*//g' |

while read FICHIER; do 
        clamdscan --quiet --no-summary -i -m "$FICHIER" --move=$QUARANTAINE
        if [ "$?" == "1" ]; then
		echo "`date` - Malware trouvé dans le fichier '$FICHIER'. Le fichier a été déplacé dans $QUARANTAINE." >> $LOG 
		echo -e "33[31mMalware trouvé!!!33[00m" "Le fichier '$FICHIER' a été déplacé en quarantaine."
		if [ -f /usr/bin/notify-send ]; then
			notify-send -u critical "ClamAV Temps Réel" "Malware trouvé!!! Le fichier '$FICHIER' a été déplacé en quarantaine."
		fi
        fi
done

Des améliorations à faire concernant mon script ? Pas de problème, celui-ci est disponible et modifiable sur la page clamav du wiki ubuntu-fr.org.

A savoir qu’il est possible d’améliorer les bases de données antivirales de clamav avec des signatures tiers en installant le paquet « clamav-unofficial-sigs« , ou manuellement avec les bases de données disponibles sur sanesecurity (toutefois une mauvaise configuration augmentera le risque de faux positifs).

Sur le site web ci-dessus, on trouve par exemple les bases de données de securiteinfo comportant 1450 signatures de malwares shell et exécutable Linux inconnu par clamav. Il est souvent dit que Linux ne craint pas les virus mais il ne faut pas confondre le terme virus avec celui de malware.
Bien que plus sûr GNU/Linux n’est pas infaillible, la popularité d’Ubuntu ou d’autres distributions accessibles vous le prouvera d’avantage. Prendre conscience de cela est le meilleur moyen de réduire la faille de sécurité chaise clavier 😉