[Unresolved:] Debian 12/KDE + manually created AppArmor profile in version 3.* for LibreWolf: Browser cannot be started

[prox]

A note in English:

For people not (enough) capable of understanding German: For a solution for the behaviour described in the heading of this forum thread refer to the next post in this thread.

---

Betreff dieses Threads auf Deutsch:

Debian 12/KDE + händisch erzeugtes AppArmor-Profil in Version 3.* für LibreWolf: Browser kann nicht gestartet werden


Hi,

nach der Installation der aktuell neuesten LibreWolf-Version 132.0.1-1 zeigte mir die GUI von LibreWolf einen Hinweis zum Inhalt dieses Links an:

Firefox unter Linux installieren - Sicherheitsfunktionen-Warnung

https://support.mozilla.org/de/kb/firef ... en-warnung

Also befasse ich mich seit vorgestern zum ersten Mal mit AppArmor.

Unter Manjaro (stabile Version, Paket-Stand aktuell) und Tuxedo OS 4 (basierend auf Ubuntu 24.04.*) laufen die dort jeweils vorhandenen LibreWolf-Installationen bisher fehlerfrei unter Einsatz eines dazugehörigen AppArmor-Profils für LibreWolf.

Unter Manjaro hat die Vorlage für den Inhalt der LibreWolf-Profildatei, wie er auf

https://support.mozilla.org/de/kb/firef ... en-warnung

genannt ist, zuerst nicht funktioniert.

Unter Manjaro musste ich deswegen mit Hilfe des Befehls aa-genprof librewolf händisch eine Profildatei für deren Verwendung durch AppArmor erzeugen. LibreWolf unter Verwendung von AppArmor funktioniert damit. Ich habe allerdings noch nicht diese Profildatei in den "enforce"-Modus umgeschaltet. Dies habe ich auch in Bezug auf die Profildatei für LibreWolf in meiner Tuxedo-OS-4-Installation noch nicht getan.

In meiner Tuxedo-OS-4-Installation funktioniert die Vorlage für den Inhalt der LibreWolf-Profildatei, welcher auf der o. g. Seite des Mozilla-Supports genannt ist.

In meiner Manjaro-Installation ist AppArmor/Abi in Version 3.* installiert.

In meiner Tuxedo-OS-4-Installation befinden sich im Verzeichnis

/etc/apparmor.d/abi/

u. a. die beiden folgenden Dateien:

- 3.0

- 4.0

Das bedeutet sehr offensichtlich, dass die AppArmor-Installation in Tuxedo OS 4 sowohl AppArmor-Profildateien in Version 3.0 als auch 4.0 erfolgreich verarbeiten kann. Deswegen kann AppArmor in Tuxedo OS 4 auch die Vorlage für den Inhalt der LibreWolf-Profildatei, wie er oben im Link des Mozilla-Supports genannt ist, erfolgreich verarbeiten.

Jetzt komme ich zu meinem eigentlichen Anliegen:

Unter Debian 12 ("Bookworm") verhindert das von mir mit Hilfe des Befehls aa-genprof händisch erzeugte AppArmor-Profil für LibreWolf den erfolgreichen Start des dort installierten LibreWolf in der aktuellen Version 132.0.1-1, das heißt:

Nach Klick auf den LibreWolf-Icon in der KDE-Taskleiste erscheint in der Taskleiste für ein paar Sekunden der LibreWolf-Umschalter-Button, verschwindet dann aber, und dann passiert nichts mehr: Der Start von LibreWolf scheitert jedes Mal.

Ohne aktives/vorhandenes AppArmor-Profil für LibreWolf in meiner Debian-12-Installation startet LibreWolf in gewohnter Weise und kann wie gewohnt benutzt werden.

Der Start von LibreWolf aus der Konsole heraus führt zu folgendem Rückgabewert:

Code: Alles auswählen

<normaler Benutzer>@<Hostname>:~$ librewolf
Couldn't load XPCOM.
<normaler Benutzer>@<Hostname>:~$

Hier die Log-Informationen über den nicht starten wollenden LibreWolf in Kombination mit dem dazu gehörigen AppArmor-Profil in meiner Debian-12-Installation:

Code: Alles auswählen

root@HOSTNAME:/var/log/audit# journalctl --system --catalog -f
Nov 11 17:09:30 HOSTNAME audit: PROCTITLE proctitle="/usr/share/librewolf/librewolf"
Nov 11 17:10:22 HOSTNAME audit[1403]: AVC apparmor="DENIED" operation="open" profile="/usr/share/librewolf/librewolf" name="/proc/1403/task/1404/stat" pid=1403 comm="librewolf" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Nov 11 17:10:22 HOSTNAME audit[1403]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7fe9138fee50 a2=0 a3=0 items=0 ppid=1400 pid=1403 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts2 ses=4 comm="librewolf" exe="/usr/share/librewolf/librewolf" subj=/usr/share/librewolf/librewolf key=(null)
Nov 11 17:10:22 HOSTNAME audit: PROCTITLE proctitle="librewolf"
Nov 11 17:10:22 HOSTNAME audit[1403]: AVC apparmor="DENIED" operation="open" profile="/usr/share/librewolf/librewolf" name="/proc/1403/stat" pid=1403 comm="librewolf" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Nov 11 17:10:22 HOSTNAME audit[1403]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=561124436721 a2=0 a3=0 items=0 ppid=1400 pid=1403 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts2 ses=4 comm="librewolf" exe="/usr/share/librewolf/librewolf" subj=/usr/share/librewolf/librewolf key=(null)
Nov 11 17:10:22 HOSTNAME audit: PROCTITLE proctitle="librewolf"
Nov 11 17:10:22 HOSTNAME audit[1403]: AVC apparmor="DENIED" operation="open" profile="/usr/share/librewolf/librewolf" name="/usr/share/librewolf/dependentlibs.list" pid=1403 comm="librewolf" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Nov 11 17:10:22 HOSTNAME audit[1403]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffea5533440 a2=0 a3=0 items=0 ppid=1400 pid=1403 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts2 ses=4 comm="librewolf" exe="/usr/share/librewolf/librewolf" subj=/usr/share/librewolf/librewolf key=(null)
Nov 11 17:10:22 HOSTNAME audit: PROCTITLE proctitle="librewolf"
[...]

Dies ist der Inhalt der von mir händisch erzeugten AppArmor-Profildatei für LibreWolf in meiner Debian-12-Installation:

Code: Alles auswählen

# Last Modified: Mon Nov 11 17:01:42 2024
abi <abi/3.0>,

include <tunables/global>

/usr/share/librewolf/librewolf {
  include <abstractions/base>

  signal send set=term peer=/usr/share/librewolf/librewolf//null-/usr/share/librewolf/librewolf,

  /sys/devices/system/cpu/cpu0/cache/index2/size r,
  /sys/devices/system/cpu/cpu0/cache/index3/size r,
  /sys/devices/system/cpu/cpu0/topology/core_cpus r,
  /sys/devices/system/cpu/cpu1/topology/core_cpus r,
  /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq r,
  /sys/devices/system/cpu/present r,
  /usr/share/librewolf/librewolf mr,
  owner /home/*/.librewolf/9uqza643.default-default/storage/permanent/ r,
  owner /home/*/.librewolf/9uqza643.default-default/storage/temporary/ r,
  owner /home/<normaler Benutzer>/.cache/librewolf/9uqza643.default-default/cache2/ r,
  owner /home/<normaler Benutzer>/.cache/librewolf/9uqza643.default-default/cache2/doomed/ rw,
  owner /home/<normaler Benutzer>/.cache/librewolf/9uqza643.default-default/cache2/entries/ rw,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/ r,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/bounce-tracking-protection.sqlite-journal w,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/datareporting/glean/db/data.safe.bin w,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/datareporting/glean/db/data.safe.tmp rw,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/formhistory.sqlite rwk,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/permissions.sqlite-journal rw,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/places.sqlite w,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/places.sqlite-wal w,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/prefs-1.js rw,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/prefs.js w,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/protections.sqlite-journal w,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/sessionCheckpoints.json w,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/sessionCheckpoints.json.tmp rw,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/storage.sqlite-journal rw,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/storage/default/ r,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/storage/permanent/chrome/idb/1657114595AmcateirvtiSty.sqlite w,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/storage/permanent/chrome/idb/1657114595AmcateirvtiSty.sqlite-wal w,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/webappsstore.sqlite rwk,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/webappsstore.sqlite-wal rw,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/xulstore.json w,
  owner /home/<normaler Benutzer>/.librewolf/9uqza643.default-default/xulstore.json.tmp rw,

}

Eine Recherche zu der Fehlermeldung "Couldn't load XPCOM" führte mich zu folgender Information:

https://support.mozilla.org/en-US/questions/1229392

Aufgrund der dort genannten Informationen habe ich das *.deb-Paket für LibreWolf gelöscht und folgende Verzeichnisse in meinem HOME-Verzeichnis gelöscht:

~/.librewolf
~/.cache/librewolf

Anschließend habe ich die AppArmor-Profildatei für den mittlerweile gelöschten LibreWolf gelöscht und einen Neustart durchgeführt.

Danach habe ich LibreWolf gemäß der Anleitung auf https://librewolf.net/installation/debian/ installiert und LibreWolf konfiguriert auf about:config und anschließend meine Bookmark-Sammlung in LibreWolf importiert, außerdem mehrere typische Aktionen in LibreWolf ausgeführt, die typisch sind für die Anwendung eines Web-Browsers.

Danach einen Neustart durchgeführt + ein neues AppArmor-Profil für LibreWolf erzeugt unter Einsatz des Befehls aa-genprof.

Die neue Profildatei hat jetzt einen ziemlich anderen, sehr kurzen Inhalt:

Code: Alles auswählen

# Last Modified: Mon Nov 11 19:45:07 2024
abi <abi/3.0>,

include <tunables/global>

/usr/share/librewolf/librewolf {
  include <abstractions/base>

  /sys/devices/system/cpu/cpu1/topology/core_cpus r,
  /usr/share/librewolf/librewolf mr,

}

Nach Erzeugung der neuen Profildatei einen Neustart durchgeführt und versucht, LibreWolf zu starten:

Es erscheint wieder die bereits oben genannte Fehlermeldung in der Konsole:

Code: Alles auswählen

<normaler Benutzer>@<Hostname>:~$ librewolf
Couldn't load XPCOM.
<normaler Benutzer>@<Hostname>:~$

Hier die Log-Informationen über den nicht starten wollenden LibreWolf in Kombination mit dem dazu gehörigen, neuem AppArmor-Profil in meiner Debian-12-Installation:

Code: Alles auswählen

root@<Hostname>:/etc/apparmor.d# journalctl --system --catalog -f
[...]
Nov 11 19:55:08 <Hostname> audit[1808]: AVC apparmor="DENIED" operation="open" profile="/usr/share/librewolf/librewolf" name="/proc/1808/task/1809/stat" pid=1808 comm="librewolf" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Nov 11 19:55:08 <Hostname> audit[1808]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7f3fd7dfee50 a2=0 a3=0 items=0 ppid=1307 pid=1808 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=4 comm="librewolf" exe="/usr/share/librewolf/librewolf" subj=/usr/share/librewolf/librewolf key=(null)
Nov 11 19:55:08 <Hostname> audit: PROCTITLE proctitle="librewolf"
Nov 11 19:55:08 <Hostname> audit[1808]: AVC apparmor="DENIED" operation="open" profile="/usr/share/librewolf/librewolf" name="/proc/1808/stat" pid=1808 comm="librewolf" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Nov 11 19:55:08 <Hostname> audit[1808]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=557f4ae04721 a2=0 a3=0 items=0 ppid=1307 pid=1808 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=4 comm="librewolf" exe="/usr/share/librewolf/librewolf" subj=/usr/share/librewolf/librewolf key=(null)
Nov 11 19:55:08 <Hostname> audit: PROCTITLE proctitle="librewolf"
Nov 11 19:55:08 <Hostname> audit[1808]: AVC apparmor="DENIED" operation="open" profile="/usr/share/librewolf/librewolf" name="/usr/share/librewolf/dependentlibs.list" pid=1808 comm="librewolf" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Nov 11 19:55:08 <Hostname> audit[1808]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffc218c6290 a2=0 a3=0 items=0 ppid=1307 pid=1808 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=4 comm="librewolf" exe="/usr/share/librewolf/librewolf" subj=/usr/share/librewolf/librewolf key=(null)
Nov 11 19:55:08 <Hostname> audit: PROCTITLE proctitle="librewolf"

Hat jemand eine Idee, wie ich das hier beschriebene Verhalten beheben könnte?

In AppArmor mich eingearbeitet für die Verwendung in Manjaro, Tuxedo OS 4 und Debian 12 habe ich mich auf der Grundlage von vor allem der beiden folgenden Links:

https://wiki.archlinux.org/title/AppArmor

https://wiki.debian.org/AppArmor/HowToUse

Viele Grüße

prox

[prox]

A note in English:

The English version of this post can be found at the end of the German text in this post.

Ich scheine das hier in diesem Thread von mir beobachtete Verhalten erfolgreich behoben zu haben.

Und zwar, indem ich eine leere Profildatei für LibreWolf in meiner Debian-12-Installation manuell erzeugt habe, und die erzeugte Profildatei mit dem Inhalt versehen habe, der in der Profildatei für LibreWolf in meiner Manjaro-Installation enthalten ist.

Hier eine entsprechende Anleitung:

1. Lösche oder verschiebe in Deiner Debian-12-Installation die ggf. vorhandene Datei

/etc/apparmor.d/usr.bin.librewolf

2. Erzeuge in Deiner Debian-12-Installation folgende Datei:

Code: Alles auswählen

# touch /etc/apparmor.d/usr.share.share.librewolf

3. Verleihe dieser Datei die numerischen Zugriffsrechte "600" unter Verwendung des folgenden Befehls:

Code: Alles auswählen

# chmod 600 /etc/apparmor.d/usr.share.share.librewolf

4. Füge folgenden Inhalt in die erzeugte Datei ein:

(Ehemaliger Inhalt von mir wieder gelöscht, da nicht zum gewünschten Ergebnis führend, plox, 16.11.2024)

5. Versetze diese Datei in den enforce-Modus mit dem Befehl:

Code: Alles auswählen

# aa-enforce /etc/apparmor.d/usr.share.share.librewolf

6. Starte Debian 12 neu.

Nach dem Neustart gibt der Befehl

Code: Alles auswählen

# aa-status

in meiner Debian-12-Installation Folgendes aus:

Code: Alles auswählen

root@<Hostname>:~# aa-status
apparmor module is loaded.
48 profiles are loaded.
26 profiles are in enforce mode.
   /usr/bin/akonadiserver
   /usr/bin/librewolf
   [...]

LibreWolf startet nun ohne Fehlermeldungen aus der Konsole heraus und über sein Programm-Icon in der Taskleiste. LibreWolf kann ohne bisher für mich erkennbare Einschränkungen wie gewohnt genutzt werden.

Rechtlicher Hinweis:

Die von mir hier in diesem Beitrag bereitgestellte Anleitung erhebt keinen Anspruch darauf, dass sie dafür dafür Sorge trägt, dass AppArmor den Betrieb des LibreWolf-Browsers in der zu erwartenden vollumfänglichen Weise absichert.

---------------------------------------------------------------------------------------------

This is the English version of this post:

It seems as if I have found a working solution for the behavior I have described earlier here in this forum thread with regard to LibreWolf, AppArmor under Debian 12 ("Bookworm").

The solution I found consists of replacing the content of the AppArmor profile file for LibreWolf which I created using the aa-genprof command in my Debian 12 installation with the content of the AppArmor profile file for LibreWolf which I created using the aa-genprof command in my Manjaro installation.

The AppArmor profile file for LibreWolf which I created in my Manjaro installation works in my Manjaro installation.

These are the instructions about how to implement the solution I found out:

1. In your Debian 12 installation delete the following file or move it to another folder outside the /etc/apparmor.d/ folder:

/etc/apparmor.d/usr.bin.librewolf

2. Create the following file in your Debian 12 installation:

Code: Alles auswählen

# touch /etc/apparmor.d/usr.share.share.librewolf

3. Assign this file the following numeric access rights: 600, i. e. with the following command:

Code: Alles auswählen

# chmod 600 /etc/apparmor.d/usr.share.share.librewolf

4. Insert the following lines into the file which you just have created:

(Original content deleted by me (prox) on 16-11-2024 because it does not return the wanted result)

5. Put this file into the enforce mode with the following command:

Code: Alles auswählen

# aa-enforce /etc/apparmor.d/usr.share.share.librewolf

6. Reboot your Debian 12 installation.

Having restarted my Debian 12 installation, the command:

Code: Alles auswählen

# aa-status

returns the following information:

Code: Alles auswählen

root@<Hostname>:~# aa-status
apparmor module is loaded.
48 profiles are loaded.
26 profiles are in enforce mode.
   /usr/bin/akonadiserver
   /usr/bin/librewolf
   [...]

LibreWolf can now successfully be started on the command line from within the console and by clicking the LibreWolf programm icon in the Task Bar. For so far, LibreWolf seems to work as usual.

Legal note:

The instructions provided here by me are without any guarantee that they will partly or completely protect your LibreWolf installation as one would expect from AppArmor.

[thunder11]

Ich hab das mal gerade in einer VM (KDE/Bookwoirm) versucht nachzuvollziehen.
Installiert nach der Anleitung: https://librewolf.net/installation/debian/

Code: Alles auswählen

apt update &&  apt install extrepo 
 extrepo enable librewolf
 apt update &&  apt install librewolf 

Der startet bei mir ohne einen einzigen Fehler im Terminal.
Da wird wohl was anderes bei dir verbogen sein.

Eine Datei /etc/apparmor.d/usr.bin.librewolf oder auch nur mit *librewolf
gibt es bei mir nicht, und wurde auch nicht angelegt.

[prox]

Hi thunder11,

die von Dir genannte Konsolen-Befehle haben nichts mit AppArmor an sich zu tun, es handelt sich bei ihnen um die für die Installation von LibreWolf notwendigen Befehle, die außerdem dafür Sorge tragen, dass ein installierter LibreWolf mit Updates versorgt wird.

AppArmor kommt deswegen in Bezug auf diese Befehle noch nicht ins Spiel, weil in Deiner VM AppArmor, falls es überhaupt schon installiert ist, noch nicht für den für AppArmor beabsichtigen Betrieb konfiguriert worden ist.

Bitte lese Dich in die Materie rund um AppArmor über die beiden Links in meinem 1. Post in diesem Thread ein, die am Ende meines 1. Posts genannt sind und in die WIKIS von ArchLinux und Debian verweisen.

Nachtrag: Gegenstand dieses Threads ist nicht eine Anleitung dahingehend, wie AppArmor und Debian 12 konfiguriert werden müssen, damit AppArmor seine Aufgaben hinsichtlich der Absicherung von Programmen und Daemons ausführen kann.

Dass AppArmor voll funktionsfähig ist, ist Voraussetzung für die Problemstellung in diesem Thread, wie ich sie in meinem 1. Beitrag dokumentiert habe.

Nachtrag II: Trotzdem vielen Dank für Deinen Versuch, die hier von mir dokumentierte Problemstellung nachvollziehen zu wollen.

[prox]

Hi thunder11,

ich möchte Dich darauf aufmerksam machen, falls Du es noch nicht bemerkt hat, dass ich meinen vorherigen Beitrag hier in diesem Thread mehrmals bearbeitet und ergänzt habe.

Gruß

prox

[prox]

Update:

The solution proposal I have provided in this thread surely does not provide any protection which AppArmoir normally provides.

I came to this conclusion because I created several AppArmor profiles during the last days for certain applications/daemons in my Manjaro installation, i. e. for among other things NetWorkManager, wpa_supplicant and cupsd.

All these applications/daemons are shown by the aa-status command this way in my Manjaro installation:

Code: Alles auswählen

[<Hostname>: ~]# aa-status
apparmor module is loaded.
13 profiles are loaded.
13 profiles are in enforce mode.
   /usr/bin/NetworkManager
   /usr/bin/cupsd
   /usr/bin/cupsd//opencl_pocl_clang
   /usr/bin/cupsd//opencl_pocl_ld
   [...]
   /usr/bin/librewolf
   [...]
   /usr/bin/wpa_supplicant
   [...]
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
4 processes have profiles defined.
4 processes are in enforce mode.
   /usr/bin/NetworkManager (548) 
   /usr/bin/cupsd (605) 
   [...] 
   /usr/bin/wpa_supplicant (590) 
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.
[<Hostname>: ~]# 

Please note the 4th line above, it says:

13 profiles are in enforce mode.

Below that line LibreWolf is mentioned.

But LibreWolf is not mentioned below the line:

4 processes are in enforce mode.

Instead, other programms/daemons are running as process protected by AppArmor, i. .e.:

- NetWorkManager
- cupsd
- wpa_supplicant

So LibreWolf is not running as a process being protected by AppArmor.

I tried to generate an AppArmor profile for LibreWolf installed in my Debian 12 installation which would work properly and would be displayed in the output of the aa-status command in Debian 12 as a LibreWolf process being protected by AppArmor, but I was not successfull.

This is in short what I did in Debian 12 when I tried to create such a profile:

Code: Alles auswählen

# aa-genprof librewolf

# aa-complain /etc/apparmor.d/usr.share.share.librewolf

Restart

Code: Alles auswählen

# aa-logprof /etc/apparmor.d -f /var/log/audit/audit.log

Restart.

I applied this command and reboot sequence for at least 7 times, trying different options to create the individual lines in the profile file for LibreWolf, but I was not able to generate a fully working AppArmor profile file for LibreWolf in Debian 12.

That is why I changed the heading of this thread to "[Unresolved] ..."

[thunder11]

Sorry, dass ich mich mehr oder weniger unwissend bez. Apparmor noch mal einmische.
Da es ja dir auch offensichtlich um den Schutz des Programms / Systems geht stellt sich mir
die Frage, warum du nicht firejail in Verbindung mit apparmor nutzt.
Apparmor hat Profile für Firejail
Firejail hat Profile für LibreWolf .

Das sieht dann bei mir so aus. Ergänzend vielleicht noch die Bemerkung, dass Firefox damit praktisch keinen Zugriff mehr auf irgendwelche Systemverzeichnisse , selbst auf mein /home hat.

Code: Alles auswählen

~# aa-status
apparmor module is loaded.
25 profiles are loaded.
23 profiles are in enforce mode.
   /usr/bin/man
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/cups/backend/cups-pdf
   /usr/lib/ipsec/lookip
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session
   /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium
   /usr/libexec/geoclue
   /usr/sbin/cups-browsed
   /usr/sbin/cupsd
   /usr/sbin/cupsd//third_party
   /usr/sbin/haveged
   /{,usr/}sbin/dhclient
   firejail-default
   libreoffice-senddoc
   libreoffice-soffice//gpg
   libreoffice-xpdfimport
   lsb_release
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
2 profiles are in complain mode.
   libreoffice-oosplash
   libreoffice-soffice
0 profiles are in kill mode.
0 profiles are in unconfined mode.
11 processes have profiles defined.
11 processes are in enforce mode.
   /usr/sbin/cups-browsed (1506) 
   /usr/sbin/cupsd (1313) 
   /usr/sbin/haveged (917) 
   /opt/firefox_beta/firefox-bin (177877) firejail-default
   /opt/firefox_beta/firefox-bin (177986) firejail-default
   /opt/firefox_beta/firefox-bin (178008) firejail-default
   /opt/firefox_beta/firefox-bin (178072) firejail-default
   /opt/firefox_beta/firefox-bin (178124) firejail-default
   /opt/firefox_beta/firefox-bin (178155) firejail-default
   /opt/firefox_beta/firefox-bin (178158) firejail-default
   /opt/firefox_beta/firefox-bin (178163) firejail-default
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.

Das mag vielleicht nicht das sein, was deiner ursprünglichen Fragestellung entspricht.
Aus meine Sicht ist das eine praktikable sehr sichere Lösung, die kein Experimentieren erfordert.

[prox]

Hi thunder11,

nee, mich stört das nicht, wenn sich hier Leute einbringen, auch wenn sie (noch) nicht so mit der Materie wie hier mit diesem AppArmor-Absicherungs-Daemon vertraut sind. Bin ich ja auch noch nicht, denn ich lerne immer noch weiter dazu, was AppArmor betrifft. Ich werde gleich noch mal hier reinschauen, vielleicht stehen da Dinge über AppArmor drin, die ich noch nicht weiß:

Profiling_with_tools

https://gitlab.com/apparmor/apparmor/-/ ... with_tools

Vielen Dank für Deinen Hinweis zu firejail - ich werde mir das nachher mal anschauen

Doch, na klar, wenn das zusätzlich über firejail geht, die Absicherung von z. B. dem LibreWolf-Browser, dann ist das genau das, was ich umsetzen möchte. Und wenn ich dann auch noch andere Programme/Daemone absichern kann (mit oder ohne Einsatz von firejail), dann umso besser

Der Hintergrund für den Thread hier ist, dass ich irgendwo im Netz meine gelesen zu haben, dass die Browser, die auf der Browser-Engine beruhen, die auch Chrome/Chromium benutzt, über eine Sandbox-Funktionalität verfügen sollen, in der sich unerwünschte Besucher aus dem Internet austoben können, ohne dass sie in das restliche System gelangen können. Chrome/Chromium sind aber aus datenschutztechnischen Gründen mittlerweile beide nicht mehr zu empfehlen, Google greift in beiden Browsern einfach zu viele Daten ab, so weit ich das mitbekommen habe.

So eine Sandbox-Funktionalität soll aber die Browser-Engine, die Firefox/LibreWolf benutzen, aber nicht haben - und genau deswegen scheint hier der Einsatz von AppArmor (in Verbindung mit firejail, falls gewünscht) so wichtig zu sein.

Viele Grüße

prox

[thunder11]

Ich geh so vor:
Habe in meinem /home/ ein Verzeichnis angelegt

Code: Alles auswählen

~/.privat-browser/Firefox/

Für meine anderen Browser ein entsprechendes Unterverzeichnis.
Das hat den Vorteil, dass die Sandbox eine Persistenz hat, und der Browser dort sein
eigenes "Universum" schafft.
Nach anlegen des Verzeichnisses werden automatisch die Programmdateien und
anderes angelegt. Auch am "Hauptbrowser" durchgeführte Updates werden ohne weiters
Zutun übernommen.
Mein Startbefehl erlegt das dann alles.

Code: Alles auswählen

firejail  --private=~/.privat-browser/Firefox/ firefox --no-remote

Danach sieht das dann so aus (Was Anderes sieht der Browser dann nicht mehr):

Code: Alles auswählen

~$ ls -lagG ~/.privat-browser/Firefox/
insgesamt 48
drwxr-xr-x 9 4096 22. Mär 2022  .
drwxr-xr-x 5 4096  8. Okt 2020  ..
-rw-r--r-- 1 3526  6. Aug 2020  .bashrc
drwx------ 6 4096 21. Sep 07:42 .cache
drwx------ 5 4096 24. Mai 2021  .config
drwxr-xr-x 3 4096 10. Apr 2024  Desktop
drwxr-xr-x 2 4096 24. Mai 2021  Downloads
-rw-r--r-- 1   26 22. Mär 2022  .inputrc
drwx------ 3 4096  6. Aug 2020  .local
drwx------ 5 4096 24. Mai 2021  .mozilla
drwx------ 2 4096  6. Aug 2020  .pki
-rw------- 1  110 17. Nov 10:49 .Xauthority

Literatur, falls noch nicht gefunden:
https://firejail.wordpress.com/

[prox]

Hi thunder11,

vielen Dank auch für Deine nächsten Hinweise zu Firejail. Ich hatte das mit dem private-browsing vorhin noch auf der Wordpress-Seite des Firejail-Projekts gesehen, das aber noch nicht so umgesetzt.

Ich musste ein paar Stunden lang an meiner Debian-12-Installation herumschrauben, bis mir klar wurde, dass jetzt Firejail in Kombination mit AppArmor funktioniert, der gestartete LibreWolf also als Firejail-Prozess über den Befehl

$ firejail --top

angezeigt wird. Und

# aa-status

spuckt jetzt das hier in meiner Debian-12-Installation aus:

Code: Alles auswählen

root@<Hostname>:/etc/apparmor.d# aa-status
apparmor module is loaded.
2 profiles are loaded.
0 profiles are in enforce mode.
2 profiles are in complain mode.
/etc/apparmor.d/firejail-default
firejail-default
0 profiles are in kill mode.
0 profiles are in unconfined mode.
10 processes have profiles defined.
0 processes are in enforce mode.
10 processes are in complain mode.
/usr/share/librewolf/librewolf (2894) firejail-default
/usr/share/librewolf/librewolf (2926) firejail-default
/usr/share/librewolf/librewolf (2974) firejail-default
/usr/share/librewolf/librewolf (3005) firejail-default
/usr/share/librewolf/librewolf (3038) firejail-default
/usr/share/librewolf/librewolf (3042) firejail-default
/usr/share/librewolf/librewolf (3101) firejail-default
/usr/share/librewolf/librewolf (3141) firejail-default
/usr/lib/libreoffice/program/oosplash (3292) firejail-default//&unconfined
/usr/lib/libreoffice/program/soffice.bin (3307) firejail-default//&unconfined
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.
root@<Hostname>:/etc/apparmor.d#

Halt, ich sehe gerade, da stehen die Firejail-Prozesse zum LibreWolf ja noch im complain-Modus drin.

Nein, ich hatte das Firejail-Profil später in den enforce-Modus umgeschaltet - funktioniert.

Bin hier gerade in meiner Manjaro-Installation, deswegen habe ich gerade keinen Zugriff auf ein laufendes Debian-12-System - weil auf meinem Rechner 3 unterschiedliche Linux-Distributionen per Grub gestartet werden können.

Firejail funktioniert ja offensichtlich nur bei Programmen, die über eine grafische Benutzeroberfläche verfügen.

Deswegen scheint Firejail nicht geeignet zu sein für das Absichern von z. B. Daemons oder diesem wpa_supplicant. Für das Absichern von Daemons und dem wpa_supplicant muss dann zurückgegriffen werden auf die dazugehörigen AppArmor-Profile, die ggf, händisch erzeugt werden müssen.

Viele Grüße und noch mal vielen Dank für Deinen Hinweis auf Firejail.

prox