freem a écrit 5019 commentaires

exercice de sécu «Red Team vs Blue Team»? J'adorerais être pris dans ce genre de trucs un jour, même à mon insu, voire, surtout à mon insu. Lire le résultat doit être super intéressant.

Si je n'arrive pas à reproduire, c'est que j'ai mal écouté le use-case et qu'il me faut revenir vers l'utilisateur.

Toi, tu bosses pas avec du hardware… parce que reproduire un bug causé par des interférences électromagnétiques fortes, causée, par exemple, par un navire qui passe ou par un putain de téléphone qui sonne juste à côté de la carte mère, c'est pas simple.
Le coup du tél on l'a trouvé par hasard (ps: kudos olivier, même si je doute que tu sois dans le coin), mais a permis de mettre en évidence le problème d'origine.
Hé oui, un bug, c'est pas toujours soft ni lié aux use-cases.

Ma foi, nous attendons tes journaux tech avec grande impatience :) Sans blague, c'est sympa de temps en temps ces journaux, j'aimerai qu'ils soient la norme.

Et tant qu'a râler, autant râler sur des sujets un peu liés au thème du coin: linux et logiciels libres. Bon, ajoutons le troll vim vs emacs sur les journaux qui n'ont rien a voir avec les éditeurs de texte, ok (si quelqu'un peut retrouvé la n'image de référénce… j'ai perdu mon bookmark).

C'est d'ailleurs comme cela qu'un lecteur de musique sous Linux réagit aux commandes systèmes type play / pause.

Ben… oui et non.

Oui, parce que je suis sûr qu'il en existe qui utilisent ça.
Non, parce que perso j'utilise mpd, et ce dernier ne réagit pas au clavier :) a la place de ça, il prend ses commandes sur un socket, avec, certes, un protocole spécifique (mais en vrai, même avec dbus, il faut implémenter un protocole, puisque qu'il faut bien définir les messages écoutés et comment y répondre, non?), que causent de nombreux clients.
J'ai nommé mpd et sa clique. Comme il existe un client en ligne de commande, il suffit de bind des raccourcis clavier aux commandes en question et le tour est joué.
LE point négatif, et j'en suis conscient, c'est qu'il faut accepter de faire la config initiale. Dans mon cas, jusqu'ici, je mets les bindings au niveau du gestionnaire de fenêtres, mais je me demande s'il ne me serais pas possible de faire ça directement au niveau d'acpid, ce qui serait plus pertinent (accessible via mes TTYs) et aussi plus portable (non spécifique à un WM, ni même à X11).

D'un autre côté, ce travail a forcément dû être fait pour les gros DEs, donc… faire faire ou faire soi-même, lorsqu'il existe possiblement des solutions déjà existantes qui seraient plus portables, sont-ce les bonnes choses à faire?
Faut que je creuse. Je connais encore trop mal certains sujets comme acpi et udev je le crains.

Bon sujet de dissertation pour un trolldi : Deux distributions Linux différentes sont-elle deux OS différents ?

Le problème est ici la définition de l'OS, de "système d'exploitation". Dans ma définition à moi, la plupart du temps, oui.
Parce que je considère les mécanismes d'installations et les ABI des libs importantes comme étant partie d'un OS et de ses specs.

Une fois que l'on considère deux distributions de Linux comme des OS distincts, c'est logique mais le newB n'a sans doute pas (encore) compris que ce sont des OS distincts.

Bien d'accord avec ce point, mais le problème n'est lié ni au newbie (qui n'étais pas un terme péjoratif dans le milieu ou j'ai appris l'info, y'a 15+ ans, il ne l'est que dans les milieux bourrés de "gamer" et de lamers) ni aux distro linux.
Le problème est lié au fait que les gens qui veulent se rendre intéressants parlent de "linux" sans comprendre ce dont il s'agit. C'est la le grand problème.

D'ailleurs, les gens que je connais ne font pas la "confusion" linux = android, et pourtant…

Euh non, quand je trouvais pas un truc sur Windows, je trouvais cela dommage mais je n'imaginais par faire l'une ou l'autre de ces cabrioles à part la première.

Tu n'as vraiment jamais installé un truc depuis un site tiers? Difficile a croire, désolé. Mais possible, en soit.
Oh, j'oubliais de lister les CDs rom achetés dans le commerce dans ma liste…

Tout à fait. Et je me dis que si un jour, j'installe une version de Linux chez quelqu'un pas très versée en ni intéressée par ce qu'il y a sous le capot; je lui dirai un truc du genre : pour ajouter des programmes tu regardes dans le catalogue (et pas ailleurs). Pas top pour l'émancipation informatique de la personne mais peut-être plus sage au départ.

Ça sera un PC qu'il n'y a pas besoin de déverminer tous les 6 mois. Et avec bien plus de logiciels que sous windows, qui ne sert juste à rien sans logiciels supplémentaires.

Deuxième dissertation pour un trolldi : si une (et une seule) solution type flatpack s'impose globalement pour l'installation des logiciels, que restera-t-il comme différences substantielles entre les différentes distributions ?

Les mêmes qu'aujourd'hui, puisque flatpack, par nature, ne peux pas remplacer le système de paquets natifs, a moins que je ne me trompe complètement.
Son objectif est, d'ailleurs, de le compléter, afin d'avoir un système qui ait la base fiable des distro "traditionnelles" orientées version, tout en ayant la modernité caractéristiques des rolling releases.

Peut-être que je me trompe du tout au tout: il me reste moi aussi une longue route à faire, mais au moins la voie est libre :)

Vivaldi le gère déjà sous Windows et Linux, par exemple avec Subsonic/Airsonic ou Youtube

Vraiment? Avec quel DE? Je suis curieux de connaître comment ça marche sous le capot (chez moi, ça marche pas, mais je pense que c'est normal, quand on choisit d'avoir un système hors normes, faut pas s'étonner que les softs soient pas très bien intégrés).

Ah, ben j'ai trouvé… diantre…

Tu fais vraiment ça? :

#!/bin/sh
#
# PROVIDE: goprogram
# REQUIRE: networking
# KEYWORD:

. /etc/rc.subr

name="goprogram"
rcvar="goprogram_enable"
goprogram_user="goprogram"
goprogram_command="/usr/local/goprogram/goprogram"
pidfile="/var/run/goprogram/${name}.pid"
command="/usr/sbin/daemon"
command_args="-P ${pidfile} -r -f ${goprogram_command}"

load_rc_config $name
: ${goprogram_enable:=no}

run_rc_command "$1"

Niveau complexité, c'est digne de systemd pour le coup, avec pleins d'artefacts qui sentent bon les race conditions en plus :)

Je préfère ne pas aller voir le contenu de . /etc/rc.subr hein…

Aie machine à Troll lancée …

On a le droit, c'est trolldi :)

je me félicite car j'ai évité systemd & co […] j'aime grave rc.d

Déjà, c'est quoi, "& co"?

Et sinon, pourquoi, du coup?
Je veux dire, systemd à de très certains défauts, mais aussi des avantages. Je n'ai aucune honte a dire que, quand je ne connaissais que les implémentations de inittab et rc.d dans debian, j'ai été SOULAGÉ d'apprendre qu'il existerais une alternative.
Dans les flamewars qui ont suivi, j'ai appris que c'était déjà le cas, et j'ai trouvé mon bonheur dans le passé plutôt que dans le futur, quand les 2 m'imposaient d'apprendre.

Ironiquement, je crois que, sans systemd, jamais runit n'aurait été considéré comme alternative à sysvinit dans Debian, et je pense sincèrement que c'est le boucan autour de systemd qui a fait qu'aujourd'hui, il y a cette alternative dans Debian.
Même si je n'aimerai probablement jamais systemd, je dois lui reconnaître ça: il a fait bouger les choses dans le bon sens.
Le bon sens, parce que j'ai vu des systèmes embarqués nécessiter une intervention de spécialiste (donc, 2 déplacement + intervention au bureau) parce qu'il y avais un système d'init tout foireux qui se contentais de lancer les trucs et baste, tant pis si ça se ferme. Des milliers d'euros de perdus, des litres de pétrole cramés pour rien.

Quels sont, en pratique, les points forts de rc.d? De ce que j'ai lu, ça semble être une sorte de /etc/inittab. Un truc certes très simple, mais qui nécessite une grosse attention quand on développe un logiciel de type daemon, sans quoi ce dernier ne sera pas relancé, ce qui est pourtant très important, surtout dans le cas d'une machine à laquelle l'on n'a pas d'accès physique (j'en ai eu pas loins de 250)…

De ce que lis… enfin, non, greppe ici, les termes "moni[toring]", "sup[ervision]", "wat[chdog]" ne sont jamais mentionnés.

Systemd n'est, bien évidemment, pas le seul a en être capable, et je n'ai aucun doute que des init et autres capables de remplir ces tâches existent sous FreeBSD (ne serait-ce que mon préféré, qui ne l'est que parce que je n'ai pas pris le temps d'en creuser 150- est portable).

Ma question ici, c'est: quel est l'intérêt de rc.d par rapport aux inits qui sont conçus avec cette problématique à l'esprit?

Tout ça pour dire, tu pourrais nourrir un peu plus les trolls quand même.

Tu sais, a ce stade, tu aurais pu linker vers lycos(d'ailleurs, je savais pas que ça existait encore), ceux qui se rappellent des pubs t'auraient probablement pertinenté :) (d'ailleurs, je vais me garder l'idée, c'est plus fun que rtfm ou
lgmtfy pour ceux qui ont le contexte)

Du coup, si tu as deux kernel avec le même nom pour deux install distinctes, il n'y a pas de collision

C'est pas plus simple d'avoir juste 2 sous-dossier différents? Quand tu fais du multiboot, tu es quand même capable de faire ça je pense?
Et je vois pas ce que ça a a voir avec l'UEFI, sauf le fait que les kernels ont tendance a se retrouver sur la partitions de boot, et… je me demande si c'est une fatalité, en soit, surtout avec des softs comme grub2 (qui n'est pas celui que j'utilise, certes, m'enfin la n'est pas la question).

il a des fonctionnalités en plus.

Ainsi que de l'overhead en plus (sur la taille minimale des paquets, par contre me semble avoir lu que c'est plus rapide à router).

Je me suis posé la question (ça me semblait bizarre quand même), pour ça que j'ai pas moinssé comme un sauvage :)

Pourquoi hors-sujet?

Je lis:

Les thèmes principaux de LinuxFr.org sont GNU/Linux et les logiciels libres

FreeBSD ne serait pas dans l'un de ces thèmes principaux?

Ben oui mais l'accès a $HOME est limité :)

Plus "sérieusement", c'était aussi pertinent que de parler de flatpack pour monitorer l'activité réelle d'une application…

Parce que bon, oui, je sais, flatpack peut, en effet, limiter les accès d'une applications a certains fichiers seulement.
Tu ne fais que réduire la liste de ce a quoi ça peut toucher, tu ne sais pas pour autant à quoi ça touche réellement. Donc tu ne peux détecter de comportement étrange.

Les seuls dossiers que j'ai par ici avec le mot policy dans le nom sont:

% find .config -iname '*policy*' 
.config/chromium/InterventionPolicyDatabase
.config/vivaldi/InterventionPolicyDatabase
.config/vivaldi/InterventionPolicyDatabase/2018.9.6.0/intervention_policy_database.pb

Ça ne semble pas correspondre a ce que tu veux?

Je me souviens que, quand j'utilisais windows XP, il y avais un «firewall»

J'ai peut-être «retrouvé» la chose: ProcessGuard mais il semble qu'il en fait un peu moins que dans mes souvenirs, et puis, je ne doute pas qu'il avait ses limites…

zonealarm, il était très intéressant de voir quel programme essayait d'accéder à quelle ressource

Ou était-ce celui-la? Je ne sais plus…

Mais oui c'était intéressant, parce que du coup tu peux corriger le problème à la source, soit en remontant un bug, soit en virant le coupable, voire tout simplement en le bridant.
Me demande s'il y a un trucsimilaire sous linux?

tu peux facilement restreindre l'accès qu'à $HOME par exemple

sudo -R chmod a-rw /. Flatpack réinventé?

Avoir une IP "stable" en DHCP

Adresse MAC?

avoir un multiboot sans soucis avec UEFI (le kernel est dans un dossier qui utilise le machine-id),

Tu peux développer? Je suis intéressé par le sujet.

Bon. Grub2 à une faille, c'est chiant, faut update, ok (vais passer un coup d'analyse sur mon syslinux cet aprem, moi, tiens).

Maintenant, avec l'uefi, les firmwares embarquent un langage de script, il me semble, ainsi que des fonctionnalités réseau.
J'aimerai bien qu'on passe un peu ces usines à gaz à l'analyse statique, moi aussi, parce qu'il me semble que la surface d'attaque est un «chouïa» plus grande.

Et puis surtout, dans le cas d'un DRM, ça serait probablement plus efficace et discret de s'appuyer sur un truc généré via les numéros de série de la machine.

C'est très simple à faire, pas besoin d'être root, j'utilisais ça au taf pour générer des hostname uniques (justement :) mais je construisais le hostname sur diverses infos pour que ça soit utilisable par ceux qui devaient se co a distance pour diverses raisons (donc: moi, entres autres), le but étant de pouvoir ssh par rebond après tout) pour les systèmes a déployer: udevadm info --query=all /dev/sda et le tour est joué.

Enfin, non, parce qu'il être sûr qu'on est bien installé sur /dev/sda, mais c'est loin d'être insurmontable: findmnt, lsblk et awk permettent largement de bricoler un truc.
Et pas besoin d'un fichier bricolable, potentiellement absent: on se base direct sur la reconnaissance du matos par le kernel.

Pas chez moi (version 68.11.0esr).

Je suis en train de regarder avec strace firefox 2>&1 | grep machine-id et en effet, je n'ai pas non plus l'impression qu'il soit accédé. Version 68.10.0esr (la màj vers la 68.11.0esr est dans le tuyau).

Pour Vivaldi, ou ce sont des gros menteurs

La question, c'est aussi: est-ce utilisé en soit par vivaldi, ou juste par chrome?
Je veux dire, ça n'excuse pas, hein, mais peut-être que c'est "pas intentionnel".

En fait, je me demande s'il existe un outil qui monitore les accès des processus au système?

Je me souviens que, quand j'utilisais windows XP, il y avais un «firewall» (pas vraiment un firewall pour moi, bien plus puissant. Je ne sais plus si libre ou freeware) qui traçais les accès des applications aux fichier, à la base de registre, au réseau, etc, et qui les bloquais, jusqu'à ce que l'utilisateur dise "ok, ce soft a le droit de faire ça (cette fois|définitivement)" via une GUI qui étais tournée vers l'efficacité, et non le bullshit et le blingbling comme la plupart des AV…
Pas impossible que mon système de l'époque, sous windows et sans anti-virus, était plus sécurisé que mes machines actuelles…

Sous linux, ça doit être techniquement possible avec SELinux et auditd, je regarde justement ces sujets depuis que j'ai posté le journal, mais je ne trouve rien de simple (comme on peut s'y attendre).

Déjà, commençons par le positif: j'ai lu le code source de quelques commandes simples provenant de:

• GNU
• FreeBSD
• OpenBSD
• NetBSD

et… il n'y a pas photo, la différence de simplicité de code est vraiment flagrante. Il y a un gros écart entre GNU et FreeBSD, un écart moyen entre FreeBSD et les 2 autres, qui sont eux très proches, net allant plus dans la simplicité et open dans la sécurité, je dirais.
Enfin, c'est ce que j'avais constaté il y a quelques années, et oui, c'est un élément que je prend maintenant en compte quand je dois apprendre a utiliser un nouvel outil: si je peux le maintenir moi-même, ou juste lire le code pour comprendre comment ça marche, ça me conforte. Et ce sentiment viens du fait que j'aie perdu bien assez de temps avec du code sale, compliqué, que personne ne sait maintenir, impliquant une réécriture.

J'ai essayé vite fait net et open sous VM, c'est bien, ça marche. Mais je ne vais pas utiliser une VM comme système principal, bien entendu.
Je ne vais pas non plus basculer a 100% mon système, j'ai aussi besoin d'être efficace, et j'aurai forcément un temps d'adaptation.
La solution logique serait le multi-boot linux/FreeBSD (puisqu'ici on parle de freebsd) mais j'ai l'impression que les BSD utilisent un système de partitionnement des plus… exotiques, justement.
Il y a aussi le problème de la partition d'échange entre les systèmes. FreeBSD sait-il lire et écrire sur ext? Sur FAT? Sur NTFS? J'ai besoin d'au moins NTFS *ou ext pour le quotidien, parce que les VMs. Bon, ok, je saurais me contenter de FAT, au pire que pourrais exploser les fichiers de plus de 4Go.

Ça, ce sont mes freins pour changer d'OS. Malheureusement, je n'ai jamais fait l'effort d'installer Debian/kFreeBSD, ça m'aurait peut-être permis un saut moins important.

Les autres questions que j'ai après lecture de cette dépêche:

• il se passe quoi si un service qui devrais être permanent plante?
• existe-t-il un outil type aptitude pour pkg? Parce que bon, 30000 paquets à lister, ça tiens pas vraiment sur mon écran… ok il y a less, m'enfin bon…

mais clairement la diversité n'est pas évidente à appréhender ni à gérer quand l'on découvre Linux

Tu pars du principe qu'il n'y a pas de diversité sous Windows ou qu'elle est plus facile a appréhender?

quand l'on découvre Linux

C'est ça le foutu problème. On ne découvre pas linux, on découvre qu'il existe de nombreux systèmes d'exploitation basés sur noyau, et on les mets tous dans le même sac, alors que bon, le noyau, c'est encore moins important que l'init du point de vue utilisateur!

Debian, Ubuntu, Fedora, Slackware, etc, ce sont des systèmes d'exploitation complets. Certains sont très proches entre eux, d'autres non, parce qu'historiquement certains sont des "forks" des autres (Ubuntu de Debian, Mint d'Ubuntu, par exemple, ou CentOS de RHEL, fedora je ne sais pas si on peut considérer ça comme un fork de RHEL? Ou l'inverse?), du coup on les considère plus ou moins comme une famille, mais au final les mettre toutes sous une seule étiquette "[GNU/]Linux" c'est pas vraiment pertinent.
Ne serait-ce que parce que, par exemple, Debian a eu des versions officielles qui n'étaient pas basées sur le noyau linux.

Oui, je crois que rien que ce dernier point montre a quel point c'est pas super pertinent. On pourrais aussi évoquer le fait que dans «les *Buntus», le simple fait de changer le nom du DE par défaut (et probablement quelques patches avec) justifie de changer le nom de l'OS, et vu que, justement, ces systèmes ciblent les débutants, je trouve cette politique pertinente.

Au final, la raison pour laquelle un débutant est confus, c'est plus parce qu'il veut considérer que les distributions linux sont ou doivent être presque pareilles.

Concernant la manière d'installer les logiciels, c'est plus discutable. Quand tu arrives et que tu piges que dalle, cela te fait chier que ces zouaves de fedora et de debian et de … ont chacun leur manière de faire parce que toi tu voulais le logiciel A et le logiciel B sur ton ordi et manque de pot pour le logiciel A c'est dispo sous fedora et le logiciel B c'est sous dispo chez debian.

Oui, vu que ce sont des systèmes d'exploitation différents, il est vrai que c'est illogique. Ou pas.
Quand un logiciel n'est pas empaqueté et mis à disposition comme tu veux sur ton OS, les solutions ont toujours été les mêmes:

• aller sur le web pour trouver une version adaptée à ton OS;
• utiliser un multi-boot;
• utiliser une VM;
• demander au fournisseur de le compiler pour ton OS;
• si possible, utiliser les sources pour le compiler soi-même;

Et ça, c'est encore plus vrai pour windows que pour les distributions linux, justement. Justement, dans les distributions linux, il y a des milliers de logiciels dans un catalogue centralisé, contrairement à windows ou macOS (ça a peut-être changé depuis, ça).

La ou ça deviens embêtant, au final, c'est pour les développeurs qui doivent faire les binaires. Et encore… je n'ai jamais eu recours à alien mais je me dis que si un dev se contente de link en statique ou utilise un langage de script (python, perl, par exemple. Pas de problèmes d'ABI au moins) le paquet ne devrais pas être trop incompatible.

La frustration est d'autant plus grande que tu comprends pas pourquoi cette différence.

Ça, c'est parce que tu es curieux et que tu veux comprendre. C'est de la frustration saine.
Je doute par contre que ça soit applicable à la plupart des utilisateurs, qui veulent que ça «juste marche».
Dans ce cas, voire mon point plus haut, au sujet des méthodes qui sont les mêmes sur les OS propriétaires quand le logiciel n'est pas dispo directement via le catalogue système.
Et je pense que dans bien des cas, justement, nos distros sont sur ce point bien moins frustrantes que, par exemple, Windows.
Je me souviens très bien de «telecharger.com» et ses malwares par exemple. J'ai du en nettoyer des machines sous windows, promis… et je pense que c'était plus frustrant pour les utilisateurs d'avoir tous les 6 mois leur machine en rade parce que windows, justement, n'a pas de catalogue d'applications (ou n'avait pas, si ça a changé).

En fait, je ne serais pas étonné que dans un futur pas si lointain l'une de ces options prennent le pas sur les autres en espérant que ce sera la meilleure.

Je n'en serais pas étonné non plus. Et tu as oublié appimage dans ta liste, ainsi que les solutions traditionnelles qui utilisent des «launchers» ou intègrent eux-même un soft de MàJ.

n'hésite pas à rejoindre la communauté francophone si tu souhaites ou si tu as des questions.

Et malgré les retours pas super délicats comme le mien peut l'être, aussi (oui, j'en avais conscience quand je l'écrivais).

Moui… mais je doute que ça se limite a ça… tu appelles quoi "précis" au juste?

Tous les systèmes de fichier que je connais allouent des blocs au fichiers, et un seul fichier peut résider par bloc.
Si ton FS est configuré pour avoir des blocs de 4Kio et que tu as 1000 fichiers d'1 octet, tu auras bel et bien 4000Kio d'utilisés, sans même prendre en compte l'espace utilisé par les structures du FS lui-même.

Je pense que, si le but est d'automatiser, les deux données les plus pertinentes à remonter sont, justement, le nombre de blocs et d'inodes libres restants, pas l'espace disque réel.