[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#47849] [PATCH 1/1] services: Add a service for the Jami daemon.
From: |
Maxim Cournoyer |
Subject: |
[bug#47849] [PATCH 1/1] services: Add a service for the Jami daemon. |
Date: |
Mon, 19 Apr 2021 08:07:25 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hi Maxime!
Maxime Devos <maximedevos@telenet.be> writes:
> 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.
It would only be able to delete directories that are world writable
though, right? Seems the opportunity to cause damage is limited, but
it's a simple check to add, so I'll do it. What about if the daemon was
run in a container (your suggestion in a following email, to which I
agree would be a good thing)? It would prevent this kind of attack,
right?
> 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).
No, it's only readable/writable by the 'jami' user of the service:
$ sudo ls -ald /var/lib/jami
drwx------ 1 jami jami 80 Apr 19 00:38 /var/lib/jami
> 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
The cleanup code is run as the 'jami' user, so I don't think it'd be
able to touch anything under /home/ANY-OTHER-USER/, unless they manually
loosened permissions on their home directory (shooting themselves in the
foot).
> Does that makes sense to you?
It does! Thanks for explaining.
Maxim