AppArmor - Profil Firefox et lib wine.

[Tawal]

Bonsoir,

Je suis en train de re-profiler firefox via les commandes aa-genprof et aa-logprof.

Jusqu'ici tout allait bien, dans le sens où je comprenais les accès demandés.
Or aujourd'hui, je suis tombé sur ce genre de demande :

Code: (extrait de la sortie aa-logprof) [Sélectionner]

Profile:  /usr/lib/firefox/firefox
Path:     /home/tawal/.PlayOnLinux/wine/linux-x86/1.9.9/lib/libgcrypt.so.11
Mode:     mr
Severity: 4

  1 - /home/tawal/.PlayOnLinux/wine/linux-x86/1.9.9/lib/libgcrypt.so.11
  2 - /home/tawal/.PlayOnLinux/wine/linux-x86/1.9.9/lib/libgcrypt.so.*
  3 - /home/*/.PlayOnLinux/wine/linux-x86/1.9.9/lib/libgcrypt.so.11
 [4 - /home/tawal/.PlayOnLinux/wine/linux-x86/1.9.9/lib/lib*so*]

[(A)llow] / (D)eny / (G)lob / Glob w/(E)xt / (N)ew / Abo(r)t / (F)inish / (O)pts
What a surprise !
Je n'arrive pas à comprendre le lien entre firefox et les lib de wine.
Dans le doute et avec un pressentiment d'étrangeté, j'ai refusé ce genre d'accès.

La question est : ai-je bien fait ?

Personnellement, je pense que oui.
J'ai mis le profil en mode enforce, et tout va bien pour le moment ...
Même si le profil n'est pas encore complet (il me manque l'ouverture de transmission par exemple ...)

Merci de m'éclairer sur le pourquoi firefox voudrait lire les lib de wine.

Au plaisir

[igor51]

Hello

si tu tapes

ldconfig -p | grep grcrypt

tu obtiens quoi ?

[Tawal]

Salut igor51,

Merci de me répondre si rapidement 

La commande ldconfig -p | grep grcrypt ne me retourne rien (à part un code retour à 1, le grep ...)

[igor51]

J'ai mal recopié

igor51@debian-laptop:~% ldconfig -p | grep  gcrypt

[Tawal]

Re,

La sortie (sans les couleurs ) :

Code: [Sélectionner]

libgcrypt.so.11 (libc6) => /lib/i386-linux-gnu/libgcrypt.so.11
Cela veut dire qu'elle est "linkée" ? Edit : oui

[igor51]

je ne sais pas...à toi de me dire.

Donc ce n'est pas normal que FF aille chercher dans ce répertoire, ou alors tu as une VE de setter quelque part.

[Tawal]

Non, elle ne l'est pas :

Code: [Sélectionner]

ll /home/tawal/.PlayOnLinux/wine/linux-x86/1.9.9/lib/libgcrypt.so.11
-rw-r--r-- 1 tawal tawal 541152 avril 29 22:07 /home/tawal/.PlayOnLinux/wine/linux-x86/1.9.9/lib/libgcrypt.so.11
Le seul rapport que je vois entre FF et Wine sont les fichiers Windows.
Or dernièrement, j'ai cherché une bébête pour tester Sophos-AV-Free pour Linux.
Peut -être que ces appels peuvent provenir de là (la navigation à haut risque).

Merci de ton aide

[igor51]

Cela veut dire qu'elle est "linkée" ? Edit : oui

Tu m'expliques ce que ça veut dire ?

[Tawal]

Cela veut dire qu'elle est "linkée" ? Edit : oui

Tu m'expliques ce que ça veut dire ?

Alors je réponds par cette investigation que j'ai faite : man ldconfig

ldconfig  crée,  met à jour et supprime les liens nécessaires.

J'ai mal cerné cette commande

[igor51]

et donc concrêtement, pourquoi je t'ai demandé de taper ça ?

Et ça veut dire quoi concretement ?

[Tawal]

plop,

je reprends demain, je m'endors là

[Tawal]

Bonjour,

et donc concrètement, pourquoi je t'ai demandé de taper ça ?

Et ça veut dire quoi concrètement ?

D'après ce que je comprends, tu m'as demandé d'entrer cette commande pour savoir si la libgcrypt.so.11 était chargée dans le cache.

Et donc, ça veut dire que cette lib est chargée dans le cache (utilisable par le système).
C'est une librairie partagée, entre autre par wine c'est sûr.

Je m'aventurerais bien à dire que chaque appel à la libgcrypt.so.11 charge en réalité /lib/i386-linux-gnu/libgcrypt.so.11.

On a aussi, par le biais de cette commande, le type ELF de la lib.
Mais là ça ne me parle pas (encore, je cherche).

Merci

[igor51]

Bonjour,

D'après ce que je comprends, tu m'as demandé d'entrer cette commande pour savoir si la libgcrypt.so.11 était chargée dans le cache.

Et donc, ça veut dire que cette lib est chargée dans le cache (utilisable par le système).
C'est une librairie partagée, entre autre par wine c'est sûr.

Je m'aventurerais bien à dire que chaque appel à la libgcrypt.so.11 charge en réalité /lib/i386-linux-gnu/libgcrypt.so.11.

Ok ça c'est bon

On a aussi, par le biais de cette commande, le type ELF de la lib.

Par contre, la, j'ai strictement rien compris.

[Tawal]

Toujours le man ldconfig

ldconfig essaye de déduire le type de bibliothèque ELF (libc 5.x ou libc 6.x, c'est-à-dire glibc) en se basant
sur la bibliothèque C utilisée pour les liens de la bibliothèque

Dans mon cas c'est libc6.
ELF = Executable and Linked Format.

[igor51]

Bon ça va c'est plus compréhensible la

[Tawal]

Bonjour,

J'avance un chouia dans mes investigations.

J'ai cherché à qui était partagé cette lib (ligcrypt.so.11)
Je suis tombé sur la commande ldd qui permet de savoir quelles libs partage un certain programme.Utile mais pas fameux pour mon cas.

Et j'ai trouvé un script reverse_ldd.sh que j'ai renommé en rldd et placé dans un dossier du PATH.
Ce qui me permet de voir que cette lib est fortement partagée :

Code: [Sélectionner]

rldd libgcrypt.so.11 | wc -l
102

Et dans la liste des programmes partageant cette lib, pas de trace de FF ni de Wine d'ailleurs !
Pourtant, elle est dans le dossier ~/.PlayOnLinux/wine/../lib/ !
Je pense donc que Wine ne partage pas cette lib et utilise la sienne localement.


Mais bon, tout ça ne m'explique pas pourquoi FF a cherché à lire cette lib.

Autre chose aussi, je n'ai pas compris ceci :

... , ou alors tu as une VE de setter quelque part.

Merci encore

Au plaisir.

[igor51]

Mouia, je ne vois pas l'intérêt de l'outil la.....

Ce que tu peux faire : tu lances FF sans apparmor (si tu n'as rien modifié pour l'instant) et ensuite, tu apprends à utiliser la commande lsof

Pour VE = variable d'environnement, je pense à une VE qui contient le path vers la libgcrypt et qui oblige FF a prendre en premier la lib de wine et non celle du système...
Tu peux aussi regarder dans le fichier /etc/ld.so.conf et dans etc/ld.so.conf.d pour voir si tu n'aurais pas quelque chose de modifier la dedans.

[Tawal]

Re,

Merci de tous ces renseignements

Je vais regarder ça.
Quant à :

je pense à une VE qui contient le path vers la libgcrypt et qui oblige FF a prendre en premier la lib de wine et non celle du système...

Si c'est le cas, alors, c'est PlayOnLinux le responsable lors de l'installation de la version 1.9.9 de Wine.


Je viens de lancer la commande en root : cat /var/log/audit/audit.log | grep apparmor

Code: [Sélectionner]

cat /var/log/audit/audit.log | grep apparmor
type=AVC msg=audit(1466203994.889:454): apparmor="DENIED" operation="mknod" parent=1 profile="/usr/lib/firefox/firefox" name="/home/tawal/.gnome2/firefox.real-ufV3g9" pid=32076 comm="firefox.real" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
type=AVC msg=audit(1466203998.697:455): apparmor="DENIED" operation="mknod" parent=1 profile="/usr/lib/firefox/firefox" name="/home/tawal/.gnome2/firefox.real-erZpLc" pid=32076 comm="firefox.real" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Je trouve bizarre aussi ces demandes (refusées, le profil est en enforce encore)

 

[igor51]

Les politiques ne sont sans doute pas complètes, surtout si tu mets à jours régulièrement le programme.

Donc à toi de le rajouter si tu considères que c'est safe.

[Tawal]

Bonjour,

Désolé de revenir si tard sur le sujet, mais j'étais pris à autre chose dernièrement.


Mes recherches m'ont permis de voir que Firefox utilise bien la bonne libgcrypt.

Code: [Sélectionner]

tawal@YAGUL:~$ sudo ldconfig -p | grep libgcrypt.so.11
libgcrypt.so.11 (libc6) => /lib/i386-linux-gnu/libgcrypt.so.11
tawal@YAGUL:~$ ps auxZ | grep -v grep |  grep firefox
/usr/lib/firefox/firefox        tawal     7079 12.0 12.0 884132 250984 ?       Sl   14:59   1:28 /usr/bin/firefox.real
tawal@YAGUL:~$ lsof -p 7079 | grep libgcrypt.so
firefox.r 7079 tawal  mem       REG        8,6   545248  655387 /lib/i386-linux-gnu/libgcrypt.so.11.7.0
tawal@YAGUL:~$ ls -l /lib/i386-linux-gnu/libgcrypt.so.11
lrwxrwxrwx 1 root root 19 févr. 15 08:49 /lib/i386-linux-gnu/libgcrypt.so.11 -> libgcrypt.so.11.7.0
tawal@YAGUL:~$
Je ne comprends toujours pas pourquoi, il  a voulu accéder à celle de wine !
Mais bon, j'ai mis les "deny" qu'il fallait au cas où ...

Quant aux lignes concernant .gnome2, comme je ne vois pas le pourquoi du comment, je les considère comme non-safe.


Je suspends ici la "mise à jour" du profil FF. Il est en mode enforce, comme on le voit avec la commande ps auxZ.

J'ai certes un FF minimaliste, mais qui fonctionne ... en sécurité ... relative 

Merci encore igor51


ps tout petit : je vois que j'ai des lacunes certaines, alors je reprends la compréhension de mon système depuis la base ...

[igor51]

Au fait, droit d'accès, mr, tu as regardé ce que ça signifiait ?

[Tawal]

Re,

r = accès en lecture
m = autorise les appels mmap de type PROT_EXEC, ça remappe la mémoire du processus et lui accorde un droit d'éxcution.



Édit :

Allow Executable Mapping (m)

    This mode allows a file to be mapped into memory using mmap(2)'s PROT_EXEC flag. This flag marks the pages executable. It is used on some architectures to provide nonexecutable data pages, which can complicate exploit attempts. AppArmor uses this mode to limit which files a well-behaved program (or all programs on architectures that enforce nonexecutable memory access controls) may use as libraries, to limit the effect of invalid -L flags given to ld(1) and LD_PRELOAD, LD_LIBRARY_PATH, given to ld.so(8.).

Je comprends mieux ta démarche avec ldconfig 

[igor51]

Bon comme je n'arrive pas à reproduire de ton FF sur mon système difficile à expliquer.

Donc tu vas apprendre une nouvelle commande (enfin si tu veux essayer de comprendre).

Je te laisse avec la commande strace

[Tawal]

Re,

Merci bien 

Je commence par là : ftp://ftp.traduc.org/pub/lgazette/html/2008/148/lg148-D.html

Cette commande n'est pas (encore) installée chez moi

[Tawal]

Plop,

J'ai peut-être cerné le pourquoi du comment.

Considérons que mon profil FF n'était (et n'est toujours) pas complet et qu'il était en mode complain

Lors de cet "apprentissage", j'ai voulu éviter les règles globales au maximum (pour être le plus fin possible).
Il se peut alors que FF ait eu accès à mon dossier perso mais pas au dossier des lib partagées (du moins pas toutes).
Il aurait donc trouvé cette lib dans le dossier ~/PlayOnLinux/../wine/lib/


Très intéressante la commande strace.

ltrace a l'air aussi sympathique.

[igor51]

Difficile à dire. mais si tu as utilisé strace sur ff, tu as pu voir qu'il balayait l'ensemble des dossiers cachés.
Les droits d'accès ne sont pas spécialement représentatifs de ce qu'il fait réellement car AppArmor n'est pas assez fin pour savoir exactement ce qu'il se passe.

[Tawal]

J'ai bel et bien utilisé strace sur FF, la sortie m'a effrayè 

Alors je me suis créé un petit script bash, rendu exécutable et j'ai lancé strace dessus avec l'option -v.
Tout ceci dans le but de comprendre les lignes en sortie.

Donc oui, j'ai usé de strace sur FF, mais pas analysé le résultat encore.

Les droits d'accès ne sont pas spécialement représentatifs de ce qu'il fait réellement car AppArmor n'est pas assez fin pour savoir exactement ce qu'il se passe.

Exactement.
Et c'est assez agaçant pour un logiciel de sécurité.
Par exemple, difficile pour un script bash utilisant rm sur des fichiers de sauvegarde de le confiner à ce qu'il n'efface que les fichiers de sauvegarde ...

Au plaisir

Merci pour ces outils et ces démarches