[bug#47849] [PATCH 1/1] services: Add a service for the Jami daemon.

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

Maxim Cournoyer schreef op za 17-04-2021 om 16:06 [-0400]:
+                      (delete-file-recursively "/var/lib/jami/.cache/jami")
+                      (delete-file-recursively "/var/lib/jami/.config/jami")
+                      (delete-file-recursively "/var/lib/jami/.local/share/jami")
+                      (delete-file-recursively "/var/lib/jami/accounts"))

You might want to verify whether /var/lib/jami/{.cache,.config,.local/share,.local}
aren't symbolic links.  That way, if the Jami daemon is compromised (due to buffer
overflow --> arbitrary code execution or something), the attacker can't trick the
shepherd service into deleting arbitrary directories.

This attack is _not_ blocked by fs.protected_symlinks.  From the sysctl documentation:
  When set to "1" symlinks are permitted to be followed only when outside
  a sticky world-writable directory, or [...]

/var/lib/jami is not world-writable (I'd hope).

Example scenario:
  * the jami daemon has a security bug that allows arbitrary code execution
    within the daemon
  * the attacker exploits this
  * now the attacker can modify everything under /var/lib/jami
  * the attacker deletes /var/lib/jami/.config and replaces it with a symlink
    to /home/ANY-USER/.config
  * eventually, the system reboots
  * (delete-file-recursively "/var/lib/jami/.config/jami") is run.
    As "/var/lib/jami/.config" points to "/home/ANY-USER/.config",
    this means "/home/ANY-USER/.config/jami" is deleted.
  * thus, ANY-USER loses their jami configuration

Does that makes sense to you?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]