car on pourra désormais voir ces process mourir dans les logs de l'utilisateur.
Car l'immense majorité des utilisateurs […] ne va pas se reconnecter ensuite pour voir s'il n'y aurait pas des mauvais comportements dans les logs ou des process fantômes […]
N'est-ce pas contradictoire ?
La plus grosse contradiction dans toute cette affaire, c'est que les soi-disant sysadmins qui se plaignent que systemd n'est pas fait pour leurs serveurs, sont les mêmes qui se plaignent de ce changement de comportement par défaut, alors qu'il est parfaitement adapté aux serveurs justement.
Comme quoi, chacun voit midi à sa porte :-)
BTW: As-tu déja utilisé nohup, dans le cadre de sysadmin ? J'imagine que non… Généralement, c'est pour faire nohup mon_script_exceptionnel_que_je_n_veux_pas_interrompre, donc bref une manipulation exceptionnelle (genre un dump de DB, reconstruction raid, etc), pas pour lancer un daemon (ça c'est parfaitement la responsabilité job d'init). Bref "indiquer clairement à init que les process qui restent sont voulus" c'est faire "nohup"… Avec ce comportement par défaut ça sera "systemd-spawn-machinchose --flag-super-important nohup mon_script", ça c'est le progrès… Aussi un "soit-disant sysadmin" utilise généralement différentes versions d'OS et différents OS, tu peux imaginer un peu le casse tête (?).
Haha, je te cites "Ne pas utiliser, recompiler… ou changer une option.". Résistance au changement ?
Sérieusement je vais te donner la bonne interprétation de mon commentaire. Je pose simplement la question de savoir si cette décision apportera une plusvalue en ce qui concerne une amélioration de la qualité des applications. J'en doute très fortement car je prends comme hypothèse que masquer des problème engendre une non-correction des bugs de la part des programmeurs, et je justifie cela non pas par leur fainéantise innée, mais parce que ces bugs ne seront tout simplement pas rapportés par les utilisateurs. Bref, dans le long terme, c'est une mauvaise décision selon moi :-)
À comparer à OpenBSD qui utilise des techniques pour révéler les bugs (p.e. un malloc particulier), et dont au final tous les OS en profitent…
(Sinon, ne t'inquiètes pas pour moi je vais m'adapter comme toujours, c'est juste qu'un jour je vais oublier que sur telle machine je dois faire les choses différemment et me faire avoir… Et puis me redemander à quoi ça sert d'avoir mis ce comportement par défaut… enfin bon la vie est pleine de contradictions :P).
s/interlocuteur néerlandophone/interlocuteur néerlandais/. Après cette correction, je te propose de relire ta "sage parole" qui pour les coups est très à propos. Si tu ne comprends pas pourquoi je relève ce paradoxe dans ton message, alors c'est qu'il peut-être déjà temps d'apprendre le nom des nos* villes en Chinois, car on m'a dit que le monde était devenu un village.
En ce qui concerne le reste de tes interventions, je me permets de te signaler que je le trouve nauséabond et insultant, en plus d'être complètement hors propos. J'espère ne pas être le seul. D'ailleurs je considère avec générosité que la majorité karmatisante est passée à côté de ton message, au risque d'enfoncer une porte ouverte.
*: j'aurais bien mis, comme toi, ce "nos" en majuscules mais j'ai peur que cela n'entraîne encore plus de confusion. C'est-à-dire que je retrouve dans ce mot justement la "sage" idée d'un contexte culturel commun, contrairement à ton usage qui en fait symbole dénué de sens objectif.
c'est pas vraiment dans le scope. Le changement apporté par Wayland, c'est pas de te protéger d'une appli qui te dit "entrer votre mot de passe", c'est de te protéger de celle qui ne te le dit pas mais qui espionne le clavier.
Je dois être bouché du cerveau, mais selon moi s'il est possible à une application de se rendre indiscernable d'une autre, ben la protection d'empêcher l'espionnage ne sert à rien. Je répètes que l'on part du principe que tout application est malveillante; pour reprendre votre exemple si en ouvrant un pdf evince exécute du code qui in fine reproduit de manière indiscernable la fenêtre d'un navigateur et que l'utilisateur utilise ce navigateur pour introduire des informations confidentielles alors le tour est joué, non ?
Tu as l'air de confondre la sécurité que xdg-app/snap veut apporter avec celle que wayland vut apporter.
Peut-être. Je ne suis pas certain de connaitre la sécurité que xdg-apps/snap veut apporter, J'ai lu un jour que les conteneurs n'ont pas été désigné comme une solution de sécurité, à contrario des jails. Probablement que cela a évolué depuis…
qu'est-ce qui nous empêche aujourd'hui de lancer un
serveur X par application
J'ai du mal à saisir si ce commentaire est destiné à promouvoir la security by obscurity ou s'il témoigne d'une sorte de tolérance envers le piratage tant que celui-ci reste anti-démocratique et favorise une sorte d'élite…
(edit: ai oublié le ;-) )
Arf j'aimerais que tu m'expliques la différence entre "se faire avoir moins facilement" et (je suppose) se faire avoir facilement. ;-)
Ensuite, cf. point 3 de ma réponse à Misc. Amha c'est une erreur de vouloir discerner des "niveaux" de compromission. I.e. "ah j'ai une application compromise mais ce n'est pas trop grave car elle ne peut pas lire ce que je tape au clavier", Voir, cela rendrait l'utilisateur encore moins responsable donc le système informatique moins sécurisé/fiable.
PS: pour moi utilisateur == administrateur, dans l'esprit GNU quoi ;-)
Je répondrai avec trois arguments/questions, le premier étant nouveau je commencerai par celui-là:
1) Est-ce que cette sécurité est bien fonctionnelle ? qu'est-ce qui permet, au moyen de Wayland, à l'utilisateur de pouvoir correctement attribuer un niveau de confiance par rapport à ce qui s'affiche à l'écran ou d'enregistrer des entrées ? Car, si je comprends bien, c'est à ça que se résume la sécurité d'un /display manager/. En d'autres mots, qu'est-ce qui empêche une application malveillante de reproduire fidèlement et de manière indiscernable mon navigateur web de telle sort que je lui fasse confiance pour introduire des informations à protéger ? QubesOS et picker issu de DROPS/L4 attribuent pour ce faire une couleur différente au cadre de fenêtre, la couleur permettant à l'utilisateur d'attribuer la confiance ou pas. Il y a-t-il quelque chose de similaire sous wayland ? ou du moins prévu sur papier ? (je redoute de recevoir comme réponse que c'est à la discrétion du compositeur… super :p )
2) Est-ce que cela est suffisant ? En reprenant l'exemple des couleurs, est-ce que l'utilisateur fera systématiquement une vérification du niveau de confiance, et sans jamais se tromper ?
3) Pour reprendre votre paraphrase et afin de réexpliquer mon précédent commentaire, n'est-ce pas vouloir boucher le trou dans la coque d'un bateau qui coule ? Pour moi le simple fait de devoir se poser la question de pouvons nous faire ou non confiance dans une application "graphique" est complètement aberrant. Car c'est admettre que le système est déja compromis… Du coups le rapport de la sécurité ajoutée (ce qui reste à démontrer*) par rapport au coût me semble bien faible. Car il a potentiellement une foultitude de moyens différents pour obtenir ces informations, sans passer nécessairement par la couche graphique… On peut rester en désaccord sur ce point. Néanmoins, un bon parano se doit de se considérer comme déja compromis.
*: l'article wayland-compositors-why-and-how-to-handle, outre le fait de passer sur de nombreux "détails" qui "restent à définir" (la "policy"), ne me semble pas assez rigoureux. Btw, qu'est-ce qui nous empêche aujourd'hui de lancer un serveur X par application et d'y ajouter un arbitre pour les interactions inter-applications (touches globales, copie d'écran, drag&drop,etc) ? Pourquoi on ne le fait pas ? Amha cela revient à régler les même problèmes de "policy" avec Wayland… Donc il me semble que la complexité d'un tel arbitre est soit largement sous-estimée soit volontairement passée sous silence.
X n'est pas idéal car il a été conçu a une époque où les contraintes de performance et de sécurité n'existaient pas.
Je dirais à la place que ces contraintes existaient belles et bien, mais qu'elles étaient différentes. Le fait que X soit un protocole qui laisse le serveur (c.-à-d. un terminal "léger") dessiner répondait justement à une contrainte de performance des équipements du réseau et des unités de traitement, qui empêchaient le simple calcul puis le transfère du rendu final depuis l'application vers le terminal. Les besoins actuels au niveau de la richesse des rendus demandés (et le matériel moderne qui les permette) renversent cette ancienne solution; parce que les contraintes et le matériel ont évolué d'une manière radicale, et non pas parce que cette ancienne solution est mauvaise "par essence".
Non pas du tout, il me semble que vous cernez bien le problème. Je ne comprends pas non-plus cette "excuse" de la sécurité.
Ok lorsque l'on utilisait X sur un réseau de manière non sécurisée c'était vraiment demander pour recevoir des ennuis. Mais bon ça fait partie de la préhistoire cela, c'était l'époque où l'on utilisait telnet et rsh de manière insouciante (en passant, depuis que j'utilise linux, la configuration par défaut de X est de ne pas écouter sur le réseau).
Autant là j'ai du mal à croire que le sand-boxer le serveur graphique est de première pertinance pour lutter contre l'insécurité… Il me semble qu'il y aie tellement d'autres vecteurs plus simples et/ou efficaces à mettre en œuvre pour pirater une machine desktop, à commencer, bien justement comme vous le dites, par tromper l'utilisateur pour lui faire installer un programme mal-veillant. Et dans ce cas, le sand-boxing de la couche graphique ne serait qu'un emplâtre sur une jambe de bois.
Tu peux toujours essayer de recompiler wine avec -fno-stack-protector, avec un peu de chance ça pourrait peut-être passer…
En faisant qq chose du genre (non testé):
activer les dépots de sources dans /etc/atp/sources.list
apt-get build-dep wine32
apt-get source wine32
cd wine-*/
env DEB_BUILD_OPTIONS=hardening=-stackprotector dpkg-buildpackage -uc -us
puis sudo dpkg -i lesbonpaquets.deb …
je cherche à faire justement l'enchaînement d'enfants
Ma suggestion serait de ne pas vouloir faire de l'enchaînement d'enfant dans le sens ou l'enfant s'occupe de lancer lui-même même la commande liée, car du coups ton enfant est obligé d'attendre lui-même le pid, ce qui t'impose de faire un double fork (et ainsi de suite pour chaque commande enchaînée), ça va devenir vite compliqué pour pouvoir gèrer correctement les redirections (i.e. dans cmd1|cmd2|cmd3, le stdout de cmd3 c'est celui du shell).
En pseudo-code ça donnerait:
tant que commande à lancer (1)
avancer le scanner
doit être pipée en sortie ?
doit être pipiée en entrée (== précédent doit être pipé en sortie) ?
(2)
forker, pipe/duper les fds et/ou redirection (< ou > ?), exec
ajouter pid à la liste d'attente
fini
tant que liste d'attente est non vide
waitpid()
pid est dans la liste d'attente, le retirer
Je te suggèrais aussi de faire cela en deux temps, c'est-à-dire à la place du (2): créer une liste d'exécution ou chaque élément serait le tuple (in redir_spec, out redir_spec, command_argv) où redir_spec := pipe | file_redirection, ensuite tu parcours une fois la liste pour créer les pipes et/ou ouvrir les fichiers de redirections, et une seconde fois pour lancer les commandes (ou les deux d'un coups mais bon j'aime pas trop, c'est mon côté programmation fonctionnelle).
Sinon ça parait normal que son code ne fonctionne pas.
En gros, il faut créer un pipe pour chaque | (logique…), puis faire un tracking correcte des programmes lancés pour le(s) waitpid(s) (amha, l'utilisation d'une liste pour cela serait naturelle…).
Deusio, comme je lui avais déjà expliqué dans une précédente question, il fait son fork beaucoup trop tôt… amah le fork doit venir au niveau de l'exec et la logique (== le calcul de comment on va faire, pas l'exécution) des pipes et des fd doit venir au dessus et créer une fonction helper fork+setup des fds+exec qui retourne un élément à mettre dans la listes des processus lancés. En gros, découper la phase d'analyse de la ligne de(s) commande(s) de la phase d'exécution(s).
Vu le message, le serveur reconnaÎt probablement* le domaine (ce qu'il y a à droite de @ dans l'adresse email) mais ne trouve pas d'user. Après il y a 36 mille façons de configurer un serveur de mail: virtual users, users système, .forward, en fonction du domaine, un mix de tout, etc.
*:fin bon je me répète, tant que le programme et la version du serveur n'est pas spécifiée, on ne peut qu'essayer de deviner. Tiens ça me fait penser que ça serait marrant d'écrire un serveur de mail qui envoit des messages d'erreurs qui n'ont aucun sens… :D
Concernant le problème 2, en effet cela doit être une problématique de configuration des MX.
Pardon mais c'est un problème de configuration du serveur mail… Sympa de vouloir encore plus l'embrouiller ;-)
host mondomaine.fr[ip.de.mon.serveur.] said: 550 sorry, no mailbox here by that name (#5.1.1) (in reply to RCPT TO command)
traduction: machine mondomaine.fr[] dis: 550 désolé pas de boîte mail à ce nom.
Bref son serveur répond, il est juste mal configuré et ne reconnaît pas l'adresse du RCPT TO en tant qu'une qu'il peut traîter. Pour info 5xx = erreur permanente ou fatale.
Déja, ton résumé ne correspond pas à ton énnoncé.
Je te conseille de te documenter (wikipedia fera l'affaire…) sur un réseau privé, les classes de routage (plus spécifiquement la différence entre un réseau routable sur internet et un non). Ensuite sur la résolution DNS et son organisation en arbre. D'ailleurs la seule façon que ton "résumé" soit plausible, c'est que les personnes externes à ton réseau recoivent une information DNS différente… Après que ces prérequis soient, non pas maîtrisés, mais au moins compris, je pense que l'on pourra reparler de serveur SMTP.
Sinon la réponse qui ne va t'avancer à rien (si ce n'est te faire patauger plus loin), c'est que tu as besoin de transformer ton PC hôte en routeur. Pour le problème 2, il se situe au niveau de la configuration du serveur mail, difficile de t'aider sans 1) avoir la configuration 2) avoir les logs du serveur 3) savoir ce que tu cherches à faire.
Normalement ton make install a du l'installer dans /usr/local/sbin vu que c'est le préfix par défaut. Tu ne dois pas non plus compiler en root ! (Fais un chown -R monuser: pour remettre les permissions des fichiers qui ont été créés pendant la compilation).
Es-tu sûr que le configure/make s'est bien terminé ? (echo $? doit afficher 0 si tu le lances juste après les dites commandes).
Est-ce que ton cross compilateur s'appelle bien gcc et non, p.e., arm-linux-gnueabihf-gcc ? Sinon fais aussi un export CC=arm-linux-gnueabihf-gcc (idem export CXX=arm-linux-gnueabihf-gcc++ si crypsetup utilise du c++). cf. sortie de ls /toolchains_for_arm/bin/gcc
c'est normale que les irq soit sauvegardées d'après le site
Non, tu n'auras que une interruption.
j'ai volontairement fais bouger cette irq pendant que les it était masqué
masquée != désactivée. Généralement une interruption est masquée lorsqu'une interruption de plus grande priorité s'exécute, automatiquement au niveau du PIC, matériel, ou d'un "soft"-IC… Au même titre qu'une "lost interrupt", ce mécanisme permet d'en récupèrer une lorsqu'elle est démasquée. Il n'y a pas de "queue", cela va à l'encontre du principe d'interruption !
J'ai du mal à saisir ton problème: quel est le problème à avoir une interruption et à se rendre compte qu'il n'y a plus de travail à faire, donc à ne rien vider ? C'est comme ça que la grosse majorité des pilotes font…
Pour la partie user-space, de la même manière que la(es) solution(s) proposée(s). I.d. en ajoutant un service serial-getty@ttyS1.service dans systemd.
Pour la partie kernel, je crains que ça ne soit pas possible. De plus, la pile USB est démarrée bien trop tard dans l'initialisation du noyau pour que cela soit intéressant. À ma connaissance, il n'est pas non plus possible de basculer la console noyau une fois le système démarré.
Un autre problème est qu'un pilote USB est autrement plus complexe: il y a plusieurs couches d'abstraction, le pilote du contrôleur usb doit encore pouvoir répondre au interruptions, etc. Contrairement au mode série où c'est un contrôleur matériel qui s'occupe du transfert des données (cela fonctionne toujours dans une certaine mesure avec les interruptions levées) et donc cela a beaucoup plus de chance de fonctionner lorsque le noyau se plante.
Ce qui se fait de mieux après la console série au niveau de la résilience, c'est la console via firewire et via réseau, mais je ne suis pas certains que ces fonctionnalités existent encore pour les noyaux récents.
Normalement il ne faut rien faire de plus que l'argument console= via le bootloader, en tout cas chez-moi-ça-marche(tm), en 115200 bauds du moins. Avez-vous essayé en 9600 ?
Posté par benja .
En réponse au message Commande dmesg | grep .
Évalué à 2.
Dernière modification le 09 avril 2016 à 11:22.
Les problèmes avec dmesg: 1) rien ne garanti que le pilote affiche effectivement la mac 2) comme l'a justement fait remarqué Tonton Benoit, la taille du log est limitée et donc à partir d'un moment les données les plus anciennes disparaissent (bien que normalement sur un système bien configuré, elles se retrouvent dans /var/log/messages).
Tu aurais une autre alternative à part la commande dmesg | grep eth0 ?
ip link show dev eth0 | awk '/link\/ether/ {print $2 }'
cat /sys/class/net/eth0/address
ifconfig eth0 | awk '/ether/ {print $2 }'
J'avais également une autre question en passant, la carte 3c501 positionnait l'adresse MAC de quelle manière ?
La mac est enregistrée dans l'eeprom de la carte. On peut la changer avec avec ethtool (ou mii-tool sur un vieux système), ainsi que le mode media sur les carte 3com (i.e. auto, ou forcer half/full duplex, 10 ou 100Mb). De manière non permanente, on peut changer la mac d'un système qui tourne avec ifconfig: ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx.
Le log kernel varie en fonction des pilotes utilisés. Chaque pilote l'utilise comme il veut. Bref, c'est tout à fait normal de ne pas avoir les même infos sur du matériel différent ou sur une version différente du noyau (ou encore d'un boot à l'autre car l'ordre d'initialisation peut varier).
Pourquoi ne pas utiliser les commandes ip ou ifconfig, voir le fichier /sys/class/net/eth0/address ?
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 6.
N'est-ce pas contradictoire ?
Comme quoi, chacun voit midi à sa porte :-)
BTW: As-tu déja utilisé nohup, dans le cadre de sysadmin ? J'imagine que non… Généralement, c'est pour faire nohup mon_script_exceptionnel_que_je_n_veux_pas_interrompre, donc bref une manipulation exceptionnelle (genre un dump de DB, reconstruction raid, etc), pas pour lancer un daemon (ça c'est parfaitement la responsabilité job d'init). Bref "indiquer clairement à init que les process qui restent sont voulus" c'est faire "nohup"… Avec ce comportement par défaut ça sera "systemd-spawn-machinchose --flag-super-important nohup mon_script", ça c'est le progrès… Aussi un "soit-disant sysadmin" utilise généralement différentes versions d'OS et différents OS, tu peux imaginer un peu le casse tête (?).
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 5. Dernière modification le 03 juin 2016 à 12:38.
Haha, je te cites "Ne pas utiliser, recompiler… ou changer une option.". Résistance au changement ?
Sérieusement je vais te donner la bonne interprétation de mon commentaire. Je pose simplement la question de savoir si cette décision apportera une plusvalue en ce qui concerne une amélioration de la qualité des applications. J'en doute très fortement car je prends comme hypothèse que masquer des problème engendre une non-correction des bugs de la part des programmeurs, et je justifie cela non pas par leur fainéantise innée, mais parce que ces bugs ne seront tout simplement pas rapportés par les utilisateurs. Bref, dans le long terme, c'est une mauvaise décision selon moi :-)
À comparer à OpenBSD qui utilise des techniques pour révéler les bugs (p.e. un malloc particulier), et dont au final tous les OS en profitent…
(Sinon, ne t'inquiètes pas pour moi je vais m'adapter comme toujours, c'est juste qu'un jour je vais oublier que sur telle machine je dois faire les choses différemment et me faire avoir… Et puis me redemander à quoi ça sert d'avoir mis ce comportement par défaut… enfin bon la vie est pleine de contradictions :P).
[^] # Re: Ne pas utiliser, recompiler… ou changer une option.
Posté par benja . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à -6.
Systemd, ou comment ne pas encourager l'écriture d'applications au comportement propre. C'est sûr, ce gars a une vision à long terme pour linux…
Scoop d'une source confidentielle: systemd 666 intégrera un anti-virus.
[^] # Re: Sage dicton
Posté par benja . En réponse au journal salut@toto — salutation, règle éditoriale et nom sur Internet. Évalué à 2. Dernière modification le 17 mai 2016 à 22:14.
s/interlocuteur néerlandophone/interlocuteur néerlandais/. Après cette correction, je te propose de relire ta "sage parole" qui pour les coups est très à propos. Si tu ne comprends pas pourquoi je relève ce paradoxe dans ton message, alors c'est qu'il peut-être déjà temps d'apprendre le nom des nos* villes en Chinois, car on m'a dit que le monde était devenu un village.
En ce qui concerne le reste de tes interventions, je me permets de te signaler que je le trouve nauséabond et insultant, en plus d'être complètement hors propos. J'espère ne pas être le seul. D'ailleurs je considère avec générosité que la majorité karmatisante est passée à côté de ton message, au risque d'enfoncer une porte ouverte.
*: j'aurais bien mis, comme toi, ce "nos" en majuscules mais j'ai peur que cela n'entraîne encore plus de confusion. C'est-à-dire que je retrouve dans ce mot justement la "sage" idée d'un contexte culturel commun, contrairement à ton usage qui en fait symbole dénué de sens objectif.
[^] # Re: Mir et Wayland périmés
Posté par benja . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 2.
Je dois être bouché du cerveau, mais selon moi s'il est possible à une application de se rendre indiscernable d'une autre, ben la protection d'empêcher l'espionnage ne sert à rien. Je répètes que l'on part du principe que tout application est malveillante; pour reprendre votre exemple si en ouvrant un pdf evince exécute du code qui in fine reproduit de manière indiscernable la fenêtre d'un navigateur et que l'utilisateur utilise ce navigateur pour introduire des informations confidentielles alors le tour est joué, non ?
Peut-être. Je ne suis pas certain de connaitre la sécurité que xdg-apps/snap veut apporter, J'ai lu un jour que les conteneurs n'ont pas été désigné comme une solution de sécurité, à contrario des jails. Probablement que cela a évolué depuis…
Noté.
[^] # Re: Mir et Wayland périmés
Posté par benja . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 0. Dernière modification le 28 avril 2016 à 01:42.
J'ai du mal à saisir si ce commentaire est destiné à promouvoir la security by obscurity ou s'il témoigne d'une sorte de tolérance envers le piratage tant que celui-ci reste anti-démocratique et favorise une sorte d'élite…
(edit: ai oublié le ;-) )
[^] # Re: Mir et Wayland périmés
Posté par benja . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 1.
Arf j'aimerais que tu m'expliques la différence entre "se faire avoir moins facilement" et (je suppose) se faire avoir facilement. ;-)
Ensuite, cf. point 3 de ma réponse à Misc. Amha c'est une erreur de vouloir discerner des "niveaux" de compromission. I.e. "ah j'ai une application compromise mais ce n'est pas trop grave car elle ne peut pas lire ce que je tape au clavier", Voir, cela rendrait l'utilisateur encore moins responsable donc le système informatique moins sécurisé/fiable.
PS: pour moi utilisateur == administrateur, dans l'esprit GNU quoi ;-)
[^] # Re: Mir et Wayland périmés
Posté par benja . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 4.
Je répondrai avec trois arguments/questions, le premier étant nouveau je commencerai par celui-là:
1) Est-ce que cette sécurité est bien fonctionnelle ? qu'est-ce qui permet, au moyen de Wayland, à l'utilisateur de pouvoir correctement attribuer un niveau de confiance par rapport à ce qui s'affiche à l'écran ou d'enregistrer des entrées ? Car, si je comprends bien, c'est à ça que se résume la sécurité d'un /display manager/. En d'autres mots, qu'est-ce qui empêche une application malveillante de reproduire fidèlement et de manière indiscernable mon navigateur web de telle sort que je lui fasse confiance pour introduire des informations à protéger ? QubesOS et picker issu de DROPS/L4 attribuent pour ce faire une couleur différente au cadre de fenêtre, la couleur permettant à l'utilisateur d'attribuer la confiance ou pas. Il y a-t-il quelque chose de similaire sous wayland ? ou du moins prévu sur papier ? (je redoute de recevoir comme réponse que c'est à la discrétion du compositeur… super :p )
2) Est-ce que cela est suffisant ? En reprenant l'exemple des couleurs, est-ce que l'utilisateur fera systématiquement une vérification du niveau de confiance, et sans jamais se tromper ?
3) Pour reprendre votre paraphrase et afin de réexpliquer mon précédent commentaire, n'est-ce pas vouloir boucher le trou dans la coque d'un bateau qui coule ? Pour moi le simple fait de devoir se poser la question de pouvons nous faire ou non confiance dans une application "graphique" est complètement aberrant. Car c'est admettre que le système est déja compromis… Du coups le rapport de la sécurité ajoutée (ce qui reste à démontrer*) par rapport au coût me semble bien faible. Car il a potentiellement une foultitude de moyens différents pour obtenir ces informations, sans passer nécessairement par la couche graphique… On peut rester en désaccord sur ce point. Néanmoins, un bon parano se doit de se considérer comme déja compromis.
*: l'article wayland-compositors-why-and-how-to-handle, outre le fait de passer sur de nombreux "détails" qui "restent à définir" (la "policy"), ne me semble pas assez rigoureux. Btw, qu'est-ce qui nous empêche aujourd'hui de lancer un serveur X par application et d'y ajouter un arbitre pour les interactions inter-applications (touches globales, copie d'écran, drag&drop,etc) ? Pourquoi on ne le fait pas ? Amha cela revient à régler les même problèmes de "policy" avec Wayland… Donc il me semble que la complexité d'un tel arbitre est soit largement sous-estimée soit volontairement passée sous silence.
[^] # Re: Mir et Wayland périmés
Posté par benja . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 8.
Je dirais à la place que ces contraintes existaient belles et bien, mais qu'elles étaient différentes. Le fait que X soit un protocole qui laisse le serveur (c.-à-d. un terminal "léger") dessiner répondait justement à une contrainte de performance des équipements du réseau et des unités de traitement, qui empêchaient le simple calcul puis le transfère du rendu final depuis l'application vers le terminal. Les besoins actuels au niveau de la richesse des rendus demandés (et le matériel moderne qui les permette) renversent cette ancienne solution; parce que les contraintes et le matériel ont évolué d'une manière radicale, et non pas parce que cette ancienne solution est mauvaise "par essence".
[^] # Re: Mir et Wayland périmés
Posté par benja . En réponse à la dépêche Sortie d’Ubuntu 16.04 LTS Xenial Xerus. Évalué à 3.
Non pas du tout, il me semble que vous cernez bien le problème. Je ne comprends pas non-plus cette "excuse" de la sécurité.
Ok lorsque l'on utilisait X sur un réseau de manière non sécurisée c'était vraiment demander pour recevoir des ennuis. Mais bon ça fait partie de la préhistoire cela, c'était l'époque où l'on utilisait telnet et rsh de manière insouciante (en passant, depuis que j'utilise linux, la configuration par défaut de X est de ne pas écouter sur le réseau).
Autant là j'ai du mal à croire que le sand-boxer le serveur graphique est de première pertinance pour lutter contre l'insécurité… Il me semble qu'il y aie tellement d'autres vecteurs plus simples et/ou efficaces à mettre en œuvre pour pirater une machine desktop, à commencer, bien justement comme vous le dites, par tromper l'utilisateur pour lui faire installer un programme mal-veillant. Et dans ce cas, le sand-boxing de la couche graphique ne serait qu'un emplâtre sur une jambe de bois.
[^] # Re: annuler ton dernier changement...
Posté par benja . En réponse au message Je n'arrive plus à ouvrir mon projet de musique / Erreur de wine. Évalué à 1. Dernière modification le 24 avril 2016 à 15:26.
Tu peux toujours essayer de recompiler wine avec -fno-stack-protector, avec un peu de chance ça pourrait peut-être passer…
En faisant qq chose du genre (non testé):
activer les dépots de sources dans /etc/atp/sources.list
apt-get build-dep wine32
apt-get source wine32
cd wine-*/
env DEB_BUILD_OPTIONS=hardening=-stackprotector dpkg-buildpackage -uc -us
puis sudo dpkg -i lesbonpaquets.deb …
[^] # Re: DIY
Posté par benja . En réponse au message Déterminer la bande passante. Évalué à 2.
Content pour toi. Pourrais-tu, peut-être, nous en faire profiter aussi ? ;-)
[^] # Re: Question ?
Posté par benja . En réponse au message Implémentations de plusieurs pipes. Évalué à 1.
Ma suggestion serait de ne pas vouloir faire de l'enchaînement d'enfant dans le sens ou l'enfant s'occupe de lancer lui-même même la commande liée, car du coups ton enfant est obligé d'attendre lui-même le pid, ce qui t'impose de faire un double fork (et ainsi de suite pour chaque commande enchaînée), ça va devenir vite compliqué pour pouvoir gèrer correctement les redirections (i.e. dans cmd1|cmd2|cmd3, le stdout de cmd3 c'est celui du shell).
En pseudo-code ça donnerait:
tant que commande à lancer (1)
avancer le scanner
doit être pipée en sortie ?
doit être pipiée en entrée (== précédent doit être pipé en sortie) ?
(2)
forker, pipe/duper les fds et/ou redirection (< ou > ?), exec
ajouter pid à la liste d'attente
fini
tant que liste d'attente est non vide
waitpid()
pid est dans la liste d'attente, le retirer
Je te suggèrais aussi de faire cela en deux temps, c'est-à-dire à la place du
(2): créer une liste d'exécution ou chaque élément serait le tuple(in redir_spec, out redir_spec, command_argv) où redir_spec := pipe | file_redirection, ensuite tu parcours une fois la liste pour créer les pipes et/ou ouvrir les fichiers de redirections, et une seconde fois pour lancer les commandes (ou les deux d'un coups mais bon j'aime pas trop, c'est mon côté programmation fonctionnelle).[^] # Re: Question ?
Posté par benja . En réponse au message Implémentations de plusieurs pipes. Évalué à 2.
Bien vu aussi pour le "bug", bien que ça n'aie aucune influence… (ben ouais, il ne vérifie pas les retours des close()…)
[^] # Re: routage et MX
Posté par benja . En réponse au message [Bluemind] Réception de mail. Évalué à 1.
Why not, mais bon tu auras plus de retours à écrire dans un forum directement.
[^] # Re: Question ?
Posté par benja . En réponse au message Implémentations de plusieurs pipes. Évalué à 3. Dernière modification le 17 avril 2016 à 17:53.
Amha dirs c'est pour rechercher dans PATH…
Sinon ça parait normal que son code ne fonctionne pas.
En gros, il faut créer un pipe pour chaque | (logique…), puis faire un tracking correcte des programmes lancés pour le(s) waitpid(s) (amha, l'utilisation d'une liste pour cela serait naturelle…).
Deusio, comme je lui avais déjà expliqué dans une précédente question, il fait son fork beaucoup trop tôt… amah le fork doit venir au niveau de l'exec et la logique (== le calcul de comment on va faire, pas l'exécution) des pipes et des fd doit venir au dessus et créer une fonction helper fork+setup des fds+exec qui retourne un élément à mettre dans la listes des processus lancés. En gros, découper la phase d'analyse de la ligne de(s) commande(s) de la phase d'exécution(s).
[^] # Re: routage et MX
Posté par benja . En réponse au message [Bluemind] Réception de mail. Évalué à 1. Dernière modification le 15 avril 2016 à 17:34.
Vu le message, le serveur reconnaÎt probablement* le domaine (ce qu'il y a à droite de @ dans l'adresse email) mais ne trouve pas d'user. Après il y a 36 mille façons de configurer un serveur de mail: virtual users, users système, .forward, en fonction du domaine, un mix de tout, etc.
*:fin bon je me répète, tant que le programme et la version du serveur n'est pas spécifiée, on ne peut qu'essayer de deviner. Tiens ça me fait penser que ça serait marrant d'écrire un serveur de mail qui envoit des messages d'erreurs qui n'ont aucun sens… :D
[^] # Re: routage et MX
Posté par benja . En réponse au message [Bluemind] Réception de mail. Évalué à 1.
Pardon mais c'est un problème de configuration du serveur mail… Sympa de vouloir encore plus l'embrouiller ;-)
traduction: machine mondomaine.fr[] dis: 550 désolé pas de boîte mail à ce nom.
Bref son serveur répond, il est juste mal configuré et ne reconnaît pas l'adresse du RCPT TO en tant qu'une qu'il peut traîter. Pour info 5xx = erreur permanente ou fatale.
[^] # Re: les MX
Posté par benja . En réponse au message [Bluemind] Réception de mail. Évalué à 1. Dernière modification le 13 avril 2016 à 21:19.
Déja, ton résumé ne correspond pas à ton énnoncé.
Je te conseille de te documenter (wikipedia fera l'affaire…) sur un réseau privé, les classes de routage (plus spécifiquement la différence entre un réseau routable sur internet et un non). Ensuite sur la résolution DNS et son organisation en arbre. D'ailleurs la seule façon que ton "résumé" soit plausible, c'est que les personnes externes à ton réseau recoivent une information DNS différente… Après que ces prérequis soient, non pas maîtrisés, mais au moins compris, je pense que l'on pourra reparler de serveur SMTP.
Sinon la réponse qui ne va t'avancer à rien (si ce n'est te faire patauger plus loin), c'est que tu as besoin de transformer ton PC hôte en routeur. Pour le problème 2, il se situe au niveau de la configuration du serveur mail, difficile de t'aider sans 1) avoir la configuration 2) avoir les logs du serveur 3) savoir ce que tu cherches à faire.
[^] # Re: Le soucis c'est ?
Posté par benja . En réponse au message Cryptsetup: help !!!. Évalué à 1.
Normalement ton make install a du l'installer dans /usr/local/sbin vu que c'est le préfix par défaut. Tu ne dois pas non plus compiler en root ! (Fais un chown -R monuser: pour remettre les permissions des fichiers qui ont été créés pendant la compilation).
Es-tu sûr que le configure/make s'est bien terminé ? (echo $? doit afficher 0 si tu le lances juste après les dites commandes).
Est-ce que ton cross compilateur s'appelle bien gcc et non, p.e., arm-linux-gnueabihf-gcc ? Sinon fais aussi un export CC=arm-linux-gnueabihf-gcc (idem export CXX=arm-linux-gnueabihf-gcc++ si crypsetup utilise du c++). cf. sortie de ls /toolchains_for_arm/bin/gcc
[^] # Re: suite irq sauvegarde
Posté par benja . En réponse au message IRQ gpio sauvegarder pendant une disable_irq comment faire pour les reseter avant un enable_irq. Évalué à 1. Dernière modification le 11 avril 2016 à 21:05.
Non, tu n'auras que une interruption.
masquée != désactivée. Généralement une interruption est masquée lorsqu'une interruption de plus grande priorité s'exécute, automatiquement au niveau du PIC, matériel, ou d'un "soft"-IC… Au même titre qu'une "lost interrupt", ce mécanisme permet d'en récupèrer une lorsqu'elle est démasquée. Il n'y a pas de "queue", cela va à l'encontre du principe d'interruption !
J'ai du mal à saisir ton problème: quel est le problème à avoir une interruption et à se rendre compte qu'il n'y a plus de travail à faire, donc à ne rien vider ? C'est comme ça que la grosse majorité des pilotes font…
[^] # Re: ttyUSB0?
Posté par benja . En réponse au journal Console sur port série avec systemd + sortie série pour grub et kernel. Évalué à 2. Dernière modification le 11 avril 2016 à 20:36.
Pour la partie user-space, de la même manière que la(es) solution(s) proposée(s). I.d. en ajoutant un service serial-getty@ttyS1.service dans systemd.
Pour la partie kernel, je crains que ça ne soit pas possible. De plus, la pile USB est démarrée bien trop tard dans l'initialisation du noyau pour que cela soit intéressant. À ma connaissance, il n'est pas non plus possible de basculer la console noyau une fois le système démarré.
Un autre problème est qu'un pilote USB est autrement plus complexe: il y a plusieurs couches d'abstraction, le pilote du contrôleur usb doit encore pouvoir répondre au interruptions, etc. Contrairement au mode série où c'est un contrôleur matériel qui s'occupe du transfert des données (cela fonctionne toujours dans une certaine mesure avec les interruptions levées) et donc cela a beaucoup plus de chance de fonctionner lorsque le noyau se plante.
Ce qui se fait de mieux après la console série au niveau de la résilience, c'est la console via firewire et via réseau, mais je ne suis pas certains que ces fonctionnalités existent encore pour les noyaux récents.
[^] # Re: Plus propre
Posté par benja . En réponse au journal Console sur port série avec systemd + sortie série pour grub et kernel. Évalué à 1.
Normalement il ne faut rien faire de plus que l'argument console= via le bootloader, en tout cas chez-moi-ça-marche(tm), en 115200 bauds du moins. Avez-vous essayé en 9600 ?
Cf. systemd-getty-generator(8) et https://github.com/systemd/systemd/blob/70a399c43a293cc4864c4e9421e265a64305cdc5/src/getty-generator/getty-generator.c#L189 .
[^] # Re: informations nécessaires
Posté par benja . En réponse au message Commande dmesg | grep . Évalué à 2. Dernière modification le 09 avril 2016 à 11:22.
Les problèmes avec dmesg: 1) rien ne garanti que le pilote affiche effectivement la mac 2) comme l'a justement fait remarqué Tonton Benoit, la taille du log est limitée et donc à partir d'un moment les données les plus anciennes disparaissent (bien que normalement sur un système bien configuré, elles se retrouvent dans /var/log/messages).
ip link show dev eth0 | awk '/link\/ether/ {print $2 }'
cat /sys/class/net/eth0/address
ifconfig eth0 | awk '/ether/ {print $2 }'
La mac est enregistrée dans l'eeprom de la carte. On peut la changer avec avec ethtool (ou mii-tool sur un vieux système), ainsi que le mode media sur les carte 3com (i.e. auto, ou forcer half/full duplex, 10 ou 100Mb). De manière non permanente, on peut changer la mac d'un système qui tourne avec ifconfig: ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx.
[^] # Re: informations nécessaires
Posté par benja . En réponse au message Commande dmesg | grep . Évalué à 2.
Le log kernel varie en fonction des pilotes utilisés. Chaque pilote l'utilise comme il veut. Bref, c'est tout à fait normal de ne pas avoir les même infos sur du matériel différent ou sur une version différente du noyau (ou encore d'un boot à l'autre car l'ordre d'initialisation peut varier).
Pourquoi ne pas utiliser les commandes ip ou ifconfig, voir le fichier /sys/class/net/eth0/address ?