Quelle est la solution de contournement 'ptrace_scope' pour les programmes Wine et existe-t-il des risques?

Réponse courte: pas encore de danger pratique, mais lisez la suite pour une meilleure façon ...

Quelle est cette chose ptrace de toute façon?

  

cela est dû à un bogue dans le noyau Ubuntu qui empêche Pace et WINE de bien jouer ensemble.

• Non, ptrace protection est une mesure de sécurité du noyau délibérée introduite pour la première fois dans Ubuntu 10.10. Ce n'est pas un bogue , et il ne va donc pas être "corrigé".

• En termes simples, la valeur par défaut ptrace_scope de 1 empêche un processus d'examiner et de modifier un autre processus à moins que le deuxième processus (enfant) ait été démarré par le premier processus ( parent).

• Cela peut causer des problèmes avec certains programmes sous Wine à cause de la façon dont wineserver fournit "Windows Services" à ces programmes.

Quels sont les risques liés à la définition de ptrace_scope à 0 ?

• Cela restaure l’ancien comportement où un processus peut "suivre" un autre processus, même s’il n’existe pas de relation parent-enfant.

• En théorie, un logiciel malveillant peut l’utiliser pour vous / votre ordinateur; par exemple. il peut se connecter à Firefox et enregistrer tous vos URL / mots de passe, etc. En pratique, cela est extrêmement improbable, sauf si vous installez aveuglément des binaires deb à partir de sites aléatoires, etc.

• En ce qui concerne le débogage, les paramètres 0 sont en fait requis pour que gdb , strace , etc. s'attache aux non-enfants à moins que vous ne les exécutiez avec des privilèges élevés (sudo). / p>

Quels sont les problèmes avec la solution de contournement?

• La solution de contournement est quelque peu problématique car ptrace_scope est une valeur globale et, même si elle est définie sur 0 , tous les processus de votre système sont exemptés de la restriction non-enfant.
• Si vous utilisez la solution de contournement, placez-la dans un simple script bash qui l'active, exécute votre programme Windows, puis désactive (définit à 1) à la sortie.
  • NE PAS rendre ptrace_scope accessible en écriture mondiale (666), comme le recommande le message du forum - ce qui représente un risque de sécurité énorme, car chaque processus peut maintenant le modifier à volonté!

Y a-t-il une meilleure solution?

• Une meilleure solution, plus sécurisée et ne nécessitant pas de modification répétitive ptrace_scope , consiste à accorder des capacités ptrace Wineserver .

  • Dans un terminal:

    sudo apt-get install libcap2-bin 
    sudo setcap cap_sys_ptrace=eip /usr/bin/wineserver
    sudo setcap cap_sys_ptrace=eip /usr/bin/wine-preloader
    

  • Ceci exempte les fichiers binaires wineserver et wine-preloader de la restriction non-ptrace, et leur permet de traiter n'importe quel processus.

  • Cela ne doit être fait qu’une seule fois et est plus sûr car ces fichiers binaires proviennent généralement d’une source fiable - les dépôts officiels ou le PPA officiel de Wine, de sorte qu’ils ne seront pas des logiciels malveillants.

Si vous utilisez Crossover

Installez libcap2:

sudo apt-get install libcap2-bin;

Ensuite, ajoutez une exception pour Crossover:

sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wineserver;
sudo setcap cap_sys_ptrace=eip /opt/cxoffice/bin/wine-preloader;

Enfin, ajoutez ses bibliothèques au fichier ld.so.conf (ou vous obtiendrez "une erreur lors du chargement des bibliothèques partagées: libwine.so.1: impossible d’ouvrir le fichier d’objets partagés: aucun fichier ou répertoire de ce type"):

echo /opt/cxoffice/lib/ | sudo tee /etc/ld.so.conf.d/crossover.conf
sudo /sbin/ldconfig

Dans la ubuntuforums.org , j'ai reçu une réponse avec le lien suivant

lien

voici le collage du lien (avec l’accent ajouté)

  

Au fur et à mesure de la popularité croissante de Linux, il deviendra une cible croissante pour les logiciels malveillants. Une faiblesse particulièrement troublante des interfaces de processus Linux est qu’un seul utilisateur est capable d’examiner la mémoire et l’état d’exécution de ses processus. Par exemple, si une application (par exemple, Firefox) était compromise, un attaquant pourrait se connecter à d'autres processus en cours d'exécution (par exemple, gpg-agent) pour extraire des informations d'identification supplémentaires et continuer à étendre leur attaque.

     

Ce n’est pas un problème théorique. Le piratage de session SSH et même l'injection de code arbitraire sont pleinement possibles si ptrace est autorisé normalement .

     

Pour une solution, certaines applications utilisent prctl () pour interdire spécifiquement cette pièce jointe ptrace (par exemple, ssh-agent). Une solution plus générale consiste à n'autoriser que ptrace directement d'un parent à un processus enfant (c.-à-d. Que gdb direct et strace fonctionnent toujours) ou en tant qu'utilisateur root (p.ex. gdb BIN PID et strace -p PID toujours en tant que root). / p>      

Ce comportement est contrôlé via la valeur sysctl / proc / sys / kernel / yama / ptrace_scope. La valeur par défaut est "1" pour bloquer pace non-enfant. Une valeur de "0" restaure le comportement antérieur plus permissif, qui peut être plus approprié pour certains systèmes de développement et serveurs avec uniquement des comptes admin. L'utilisation de "sudo" peut également accorder temporairement des autorisations ptrace via la fonctionnalité CAP_SYS_PTRACE, bien que cette méthode permette le traitement de tout processus.

Je pense donc que la réponse courte serait que c'est moins sûr mais que le capot d'un ordinateur personnel qui subit ce genre d'attaques serait plutôt mince.