From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Maxime Devos <maximedevos@telenet.be>
Cc: 47849@debbugs.gnu.org
Subject: [bug#47849] [PATCH 1/1] services: Add a service for the Jami daemon.
Date: Mon, 19 Apr 2021 08:07:25 -0400 [thread overview]
Message-ID: <87czuqiiki.fsf@gmail.com> (raw)
In-Reply-To: <1e9354c0744afc2d5d11d3eeecaba31f62e59e65.camel@telenet.be> (Maxime Devos's message of "Sun, 18 Apr 2021 13:41:06 +0200")
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
next prev parent reply other threads:[~2021-04-19 12:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-17 20:04 [bug#47849] [PATCH 0/1] [preview] Add a jami-daemon service Maxim Cournoyer
2021-04-17 20:06 ` [bug#47849] [PATCH 1/1] services: Add a service for the Jami daemon Maxim Cournoyer
2021-04-18 11:41 ` Maxime Devos
2021-04-19 12:07 ` Maxim Cournoyer [this message]
2021-04-19 14:41 ` Maxime Devos
2021-04-19 15:42 ` Maxim Cournoyer
2021-04-18 11:47 ` Maxime Devos
2021-04-19 12:08 ` Maxim Cournoyer
2021-05-20 12:31 ` [bug#47849] [PATCH v2] " Maxim Cournoyer
2021-05-20 12:37 ` [bug#47849] [PATCH 1/1] " Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czuqiiki.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=47849@debbugs.gnu.org \
--cc=maximedevos@telenet.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.