GNU bug report logs - #47849
[PATCH] Add a jami-daemon service.

Previous Next

Full log

Message #17 received at 47849 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 47849 <at> debbugs.gnu.org
Subject: Re: [bug#47849] [PATCH 1/1] services: Add a service for the Jami
 daemon.
Date: Mon, 19 Apr 2021 08:07:25 -0400

Hi Maxime!

Maxime Devos <maximedevos <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.