gUI a écrit 5994 commentaires

Démontage, coup de soufflette… ça ne fait jamais de mal !

Au boulot j'avais un PC qui plantait quand je lançais la compil d'un système complet Android (4h de compil' tout de même). En le posant comme un livre (sur la tranche donc), il refroidissait bcp mieux, et ne plantait plus.

Un coup de soufflette plus tard, il ne plantait plus du tout, même posé à plat (normalement).

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Je me doute bien, mais ma question était sur la disponibilité de la vidéo. Selon l'hébergement (le pays), il était plus ou moins facile de la virer.

De ce que je comprends, c'est le divulgateur lui-même qui l'a virée après la démission.

EDIT : ma question était pas très claire, mais le journal parle des réseaux sociaux, or c'est bien un site web classique (blog) qui a été à l'origine de la divulgation. alors RS ou pas, si le site est encore dispo ça ne sert à rien de s'offusquer ou de censurer quoi que ce soit sur Facebook/Twitter. d'où ma question si le site est encore public. je n'avais pas l'intention de provoquer qqu'un à comettre la grosse erreur de donner l'accès à cette vidéo.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Apparemment non, mais on a quelques infos sur la date du dépôt de nom de domaine, l'hébergement etc.

Bref rien d'extraordinaire, sauf une belle préméditation.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

D'ailleurs le site original est toujours ouvert ? L'URL est-elle publique ?

Réponse : non, le site d'origine n'est plus dispo (fermé par le créateur ou par la plateforme, c'est pas très clair).

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

curieux il me semblait bien l'avoir fait… là c'est sur c'est fait :)

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

fait :)

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Oui je pense que ça marche pas dans le titre.

Mais merci pour le message en tous cas, ça fait bien plaisir.

L'équipe de modération, toujours à votre service ! \o/

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

On est plein dans ton cas je pense, ou en tous cas un truc qui ressemble.

Du coup je mise sur la documentation. Déjà mettre clairement sur un papier où est le nom de domaine, où est hébergé le site, et les mots de passe, c'est bcp. Même si personne dans l'asso ne saura s'en servir, ils pourront toujours trouver qqu'un qui saura les dépatouiller.

Donc fait un truc simple (par exemple moteur de blog) et écrit clairement qu'est-ce qui est fait et où. Tu peux aussi documenter une ou deux procédures pour qu'ils fassent eux-même quelques opérations simples mais essentielles (comme renouveler le paiement de l'hébergement et/ou du nom de domaine).

Au passage, fait tout au nom de l'asso et pas en ton nom (donc création d'une compté spécifique auprès de l'hébergeur).

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Je connaissais pas, merci !

Une belle part de la langue Anglaise vient du Français (30% environ), et pas mal de mots on ainsi fait l'aller-retour. Un exemple assez connu est "ticket" qui vient de "étiquette". Il y a aussi "flirt" qui vient de "compter fleurette".

Par contre "bateau" vient de "boat", et pas l'inverse.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

La config dhcp je n'y ai pas touché.

une bonne idée serait déjà de donner une IP fixe à ton serveur. pas de dépendance à la box, il peut faire a vie tout seul.

• tu règles ta box pour avoir un dhcp par exemple entre xx.xx.xx.50 et entre xx.xx.xx.255 (ne pas utiliser toute la plage, donc laisser des IPs libre, donc mon exemple c'est de xx.xx.xx.1 à xx.xx.xx.49)
• tu mets par exemple une IP xx.xx.xx.10 à ton serveur

déjà tu vois si ça fait quelque chose.

ensuite il est ouvert sur Internet ? tu forwardes des ports de ta box vers lui ? tu parles de fail2ban par exemple, mais c'est sur l'interface du réseau local ?

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

bin même ça je suis pas sûr que ça marche. c'est le mot de passe qui transite (chiffré) ou c'est un hash (chiffré aussi) ?

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Oui mais à un moment, coté serveur, on doit doit bien pouvoir le récupérer non?

Pas forcément. Le serveur peut recevoir le hash du mot de passe par exemple. Il compare avec le sien et ça suffit à savoir si le mot de passe est le bon.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Tu as donc raté deux modes : celle d'aller sur Fb et celle de le quitter :)

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

token month { '0'<[0..9]> || '1'<[1..2]> }

Tu chopes le mois "10" avec ça ?

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Youhou \o/

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

En tous cas quand tu regardes la page de Total sur le JET A-1, ils parlent plus de ça que de propreté éventuelle du carburant.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Mais est-ce que le code C en question est écrit directement par des humains ?

C'est souvent un mix. En général tu trouves les lois de pilotage, la mécanique de vol, les logiques des alarmes etc. sous forme de planche Scade (écrit par des non informaticiens), mais il reste bcp de code manuel à faire (ne serait-ce que le boot, les drivers, bref l'intégration du code généré par Scade).

Et on ne relit pas le code généré par Scade. L'outil est certifié, c'est à dire qu'on a plus de confiance dans l'outil que dans le relecteur. Donc ça servirait à rien de relire, vaut mieux dépenser de l'énergie à relire les planches Scade en amont, ou faire des tests en aval.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Le but étant d'empêcher un utilisateur lambda de pouvoir utiliser certaine commande dans /usr/sbin

Mais c'est déjà le cas. Les commandes "sensibles" ont besoin de privilèges (on les exécute via sudo en général) et un utilisateur lambda n'a pas ces privilèges.

Tu as un exemple concret de commande que tu veux interdire ?

EDIT : oups, tu parles de reboot en effet. Bin tu fais un chmod o-x sur la commande reboot et c'est plié. D'autres exemples ?

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Je croyais qu'un avion était rempli d'avionique conçu pour une (ou quelques) familles

Pas tant que ça. Ce qui a été développé pour l'A380 n'a donc été produit que pour 250 avions au final. Ensuite on n'est pas reparti de zéro pour l'A350, mais là encore c'est pas des chiffres du monde automobile : l'A350 qui est un très gros succès commercial arrive presque à 1000 avions vendus. Bon après le coût est important, mais ne fait pas tout non plus.

Du coup en quoi c'est compliqué et/ou cher d'avoir des diodes physiques dans le design ?

Parce qu'il faut interpréter des messages ARINC (surcouche d'ethernet). On est dans le schéma d'un firewall quoi.

seul le logiciel diode en question peut piloter côté sécurisé

On est d'accord c'est le cas.

mais est-il audité par des chercheurs indépendants en sécu informatique appliquant des tests d'attaque de l'état de l'art

Je ne sais pas mais je pense que oui. Avant (de mon temps) ça ne se faisait clairement pas. On ne parlait que de safety et pas de security. Mais maintenant il y a clairement une prise en compte de la sécurité informatique à bord, et je me doute que c'est le composant qu'ils sont allés regarder en premier. Je peux me renseigner, j'ai un pote qui a bossé en security un temps. En tous cas les avions étant principalement certifiés Europe et USA, il y a une tripotée de nouvelles normes qui ont été ajoutées par les 2 parties ces 10 dernières années (plus ou moins en accord, c'est déjà ça).

dans les industries un peu "opaques"

Alors je ne sais pas trop ce que tu entends par "opaque", mais clairement il n'y a pas de secret d'état dans les code source des avions. Certes t'as pas de Github à dispo pour le soumettre au public, mais il n'y a aucune contrainte (NDA, habilitation secret défense) pour bosser là-dedans. D'ailleurs énormément de développement est externalisé (y compris en Chine et en Inde) comme n'importe quel domaine industriel.

Ensuite il y a des process de développement qui sont très poussés, là on parle de DO178B niveau A, tu dois passer à la louche 5x plus de temps à tester et à documenter qu'à coder (ce qui n'empêche pas de se méfier et d'auditer, on est d'accord).

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Le kérosène est distillé entre le gazoil et l'essence, je ne vois pas ce qui en fait un truc plus pur qu'un autre. Et pour en avoir senti beaucoup, ça sent pas la rose, crois-moi.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

J'aimerai en premier lieu interdir l'accès au /usr/sbin

D'abord, pourquoi ? Chez moi par exemple (Arch) c'est un lien vers /usr/bin, autant dire que ça va moins bien marcher si j'interdis à quiconque d'y aller :)

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Si je comprends bien, c'est une diode logicielle, n'est-ce pas ?

Oui

N'est-ce pas un peu dommage de se contenter de ça alors qu'on peut avoir un niveau de garantie bien plus élevé avec des garanties physiques sur la diode ?

Bin toujours pareil, le coût de développement par rapport au gain. La garantie voulue est atteinte en logiciel. C'est assez simplement fait en logiciel (on est dans un monde très contraint, c'est trivial de savoir ce qu'on accepte, donc on refuse tout le reste), et je suppose que le développement d'un hardware dédié a peut-être été jugé trop cher ? (les avions ce sont des petites séries, en centaine/milliers d'exemplaires au plus).

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Jusqu'à il y a peu, l'IFE était sous Windows CE

J'ai bossé sur celui de l'A350, le serveur était déjà sous Linux, suite d'ailleurs aux mésaventures de celui de l'A380 qui était sous Windows. Pour les clients, je ne sais pas trop l'évolution (c'était Airbus Allemagne qui le gérait je crois).

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Perso je serais plus emmerdé que Amazon sache ce que je lis (ce qui est le cas évidemment) plutôt que sur quels boutons j'ai dû appuyer (sûrement à des fins de statistique). Je risque pas de voir la Gestapo débouler chez moi parce que j'ai trop appuyé sur le bouton LEFT. Par contre, avec mes livres d'économiste gauchiste… .

Et le pire c'est que bon, j'ai pas de liseuse, mais vu tout ce que j'achète chez Amazon (y compris des livres d'économiste gauchiste), ils savent déjà.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Je profite de la blagounette pour expliquer un peu.

J'ai bossé pour Airbus sur plusieurs systèmes avioniques, et notamment l'IFE (In Flight Entertainment) qui est justement le système destiné aux passagers (et à l'équipage). Ce système ne gère pas l'avion, il ne pilote pas (il est dans ce qu'on appelle "le monde ouvert"). Il est en charge entre autre :
- des applications et vidéos pour les passagers
- des applications spécifiques compagnie aérienne (la voix enregistrée qui vous raconte les issues de secours pendant que personne ne regarde)
- d'applications pour l'équipage (consulter le niveau d'eau propre et d'eau sale, régler la luminosité de la cabine, mettre une musique d'ambiance…)

Ce système a besoin de certaines informations de vol (donc provenant des systèmes critiques), comme par exemple le statut "au sol" / "en vol", ou la vitesse et la position de l'avion pour l'afficher justement aux passagers. Il ne peut donc pas totalement être isolé des systèmes avioniques (ceux qui pilotent l'avion).

Il y a donc un sous-système, surnommé "la diode" qui comme son nom l'indique ne laisse passer les informations que dans un sens : de l'avionique vers "le monde ouvert". Au passage elle ne laisse passer que certaines informations précises (whitelist).

Cette "diode" est tellement simple dans sa conception, que j'ai une très grande confiance en elle (elle est développée sous DO178B niveau A si ma mémoire est bonne), et que si un crash arrive et qu'on commence à soupçonner que à bord un passager a réussi à piloter l'avion à distance, je ne le croirai pas une seule seconde. Je sais que tout est possible dans la vraie vie, mais il me faudra autre chose que des soupçons pour changer d'avis.

Au passage, même avec l'IFE qui n'est donc pas critique, il y a déjà eu un accident (mais pas catastrophique je crois)… une surchauffe des câbles qui a causé un incendie à bord. Comme quoi ça empêche pas d'être vigilent, même sur des systèmes non critiques.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.