Report forwarded
to guix-security@gnu.org, guix-maintainers@gnu.org, bug-guix@gnu.org: bug#37744; Package guix.
(Mon, 14 Oct 2019 07:48:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Ludovic Courtès <ludo@gnu.org>:
New bug report received and forwarded. Copy sent to guix-security@gnu.org, guix-maintainers@gnu.org, bug-guix@gnu.org.
(Mon, 14 Oct 2019 07:48:02 GMT) (full text, mbox, link).
Added tag(s) security.
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Mon, 14 Oct 2019 07:55:01 GMT) (full text, mbox, link).
Severity set to 'important' from 'normal'
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Mon, 14 Oct 2019 07:55:02 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Mon, 14 Oct 2019 07:59:02 GMT) (full text, mbox, link).
Cc: GNU Guix maintainers <guix-maintainers@gnu.org>, guix-security@gnu.org
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Mon, 14 Oct 2019 09:58:47 +0200
Ludovic Courtès <ludo@gnu.org> skribis:
> Looks like we’ll need to do something similar to:
> <https://github.com/NixOS/nix/pull/3136/commits/5a303093dcae1e5ce9212616ef18f2ca51020b0d>.
Compared to the Nix build daemon, our daemon can accept connections over
TCP in addition to Unix-domain sockets, so the bit that does:
store->createUser(userName, userId);
won’t work in that context (it would create ‘per-user/root’.)
I don’t see how to let the daemon create ‘per-user/$USER’ on behalf of
the client for clients connecting over TCP. Or we’d need to add a
challenge mechanism or authentication.
Thoughts?
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Mon, 14 Oct 2019 11:54:02 GMT) (full text, mbox, link).
Ludo',
Thanks for your report :-p
The 1777 is obviously very bad, no question. However: question:
Ludovic Courtès 写道：
> I don’t see how to let the daemon create ‘per-user/$USER’ on
> behalf of
> the client for clients connecting over TCP. Or we’d need to add
> a
> challenge mechanism or authentication.
I need more cluebat please: say I'm an attacker and connect to
your daemon (over TCP, why not), asking it to create an empty
‘per-user/ludo’.
Assuming the daemon creates it with sane permissions (say 0755) &
without any race conditions, what's my evil plan now?
Kind regards,
T G-R
Cc: GNU Guix maintainers <guix-maintainers@gnu.org>,
Ludovic Courtès <ludo@gnu.org>, 37744@debbugs.gnu.org,
guix-security@gnu.org
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Mon, 14 Oct 2019 12:37:49 -0400
Hello,
Tobias Geerinckx-Rice <me@tobias.gr> writes:
> Ludo',
>
> Thanks for your report :-p
>
> The 1777 is obviously very bad, no question. However: question:
>
> Ludovic Courtès 写道：
>> I don’t see how to let the daemon create ‘per-user/$USER’ on behalf
>> of
>> the client for clients connecting over TCP. Or we’d need to add a
>> challenge mechanism or authentication.
>
> I need more cluebat please: say I'm an attacker and connect to your
> daemon (over TCP, why not), asking it to create an empty
> ‘per-user/ludo’.
>
> Assuming the daemon creates it with sane permissions (say 0755) &
> without any race conditions, what's my evil plan now?
>
> Kind regards,
>
> T G-R
It's not yet clear to me how an actual attack would work, but IIUC when
connecting over TCP there's no 'trusted' way to verify the user is
actually the user it says they are; so they could impersonate at will
(and make use of another user's local directory, perhaps arranging to
write something nasty in there).
Is my understanding correct?
Maxim
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Tue, 15 Oct 2019 12:36:02 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Tue, 15 Oct 2019 14:34:46 +0200
Hi!
Tobias Geerinckx-Rice <me@tobias.gr> skribis:
> The 1777 is obviously very bad, no question. However: question:
>
> Ludovic Courtès 写道：
>> I don’t see how to let the daemon create ‘per-user/$USER’ on behalf
>> of
>> the client for clients connecting over TCP. Or we’d need to add a
>> challenge mechanism or authentication.
>
> I need more cluebat please: say I'm an attacker and connect to your
> daemon (over TCP, why not), asking it to create an empty
> ‘per-user/ludo’.
You wouldn’t be able to do that because over TCP because the daemon
can’t tell what user you are.
Note that TCP has to be explicitly enabled through ‘guix-daemon
--listen=0.0.0.0’. It’s meant for cluster setups where you have one
head node that clients connect to from remote nodes.
I suppose we won’t be able to address the problem in this particular
setup, unless we had some authentication mechanism like I wrote above
(it could be a challenge like the MIT-MAGIC-COOKIE.)
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Tue, 15 Oct 2019 14:32:01 GMT) (full text, mbox, link).
Ludo',
Thanks for your answer.
Ludovic Courtès 写道：
>> I need more cluebat please: say I'm an attacker and connect to
>> your
>> daemon (over TCP, why not), asking it to create an empty
>> ‘per-user/ludo’.
>
> You wouldn’t be able to do that because over TCP because the
> daemon
> can’t tell what user you are.
No, I ask it nicely: ‘hullo daemon, I'm, er, "ludo"’.
Of course the remote daemon doesn't trust me beyond pre-creating
an empty per-user directory owned by the local "ludo" user only if
such a user exists. It doesn't even report succes or failure to
avoid leaking valid user names.
You already trust the network not to DoS you with webkitgtks, how
does this new step decrease security?
Sure, it bumps the protocol version; I'm aware of that.
> It’s meant for cluster setups where you have one
> head node that clients connect to from remote nodes.
And likely some kind of centralised user management so it's not
unreasonable to handle this differently/manually.
Kind regards,
T G-R
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 08:57:05 +0200
Hi Tobias,
Tobias Geerinckx-Rice <me@tobias.gr> skribis:
> No, I ask it nicely: ‘hullo daemon, I'm, er, "ludo"’.
>
> Of course the remote daemon doesn't trust me beyond pre-creating an
> empty per-user directory owned by the local "ludo" user only if such a
> user exists. It doesn't even report succes or failure to avoid
> leaking valid user names.
Ah you’re right, the worst that can happen is that an empty directory is
created for someone else. Sounds like a plan.
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 10:23:01 GMT) (full text, mbox, link).
Hello!
Here’s a patch that fixes the issue, partly based on what the Nix folks
did.
For the client-connecting-over-TCP case, I added special handling:
‘set-build-options’ now passes a “user-name” property, potentially
allowing to create ‘per-user/$USER’ at that point (like you suggested,
Tobias.)
In a cluster setup, it means that the machine that runs ‘guix-daemon’
must see the same users as the machines where its clients run, but
that’s basically already what we expect:
<https://hpc.guix.info/blog/2017/11/installing-guix-on-a-cluster/>.
There’s one case that won’t be correctly handled: in a cluster setup, an
old client talking to a new daemon won’t provide info to create
‘per-user/$USER’, and thus ‘guix package’ & co. won’t be able to create
the user’s profile it it doesn’t already exist. I think that’s hard to
avoid though.
Thoughts?
Thanks,
Ludo’.
From 07126db581f1854a2235c271fcdaecfb36705d5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo@gnu.org>
Date: Wed, 16 Oct 2019 12:16:20 +0200
Subject: [PATCH 2/2] DRAFT news: Add entry for security issue with
/var/guix/profiles/per-user.
DRAFT: Update commit before pushing.
* etc/news.scm: Add entry for security issue in multi-user setups.
---
etc/news.scm | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/etc/news.scm b/etc/news.scm
index e19dec38dd..afcf5fadaa 100644
--- a/etc/news.scm
+++ b/etc/news.scm
@@ -9,6 +9,27 @@
(channel-news
(version 0)
+ (entry (commit "FIXME")
+ (title (en "Security issue with profiles in multi-user setups"))
+ (body
+ (en "The default user profile, @file{~/.guix-profile}, points to
+@file{/var/guix/profiles/per-user/$USER}. Until now,
+@file{/var/guix/profiles/per-user} was world-writable, allowing the
+@command{guix} command to create the @code{$USER} sub-directory.
+
+On a multi-user system, this allowed a malicious user to create and populate
+that @code{$USER} sub-directory for another user that had not yet logged in.
+Since @code{$USER} is in @code{$PATH}, the target user could end up running
+attacker-provided code. See @uref{https://issues.guix.gnu.org/issue/37744}
+for more information.
+
+This is now fixed by letting @command{guix-daemon} create these directories on
+behalf of users and removing the world-writable permissions on
+@code{per-user}. On multi-user systems, we recommend updating the daemon now.
+To do that, run @code{sudo guix pull} if you're on a foreign distro, or run
+@code{sudo guix pull && sudo guix system reconfigure @dots{}} on Guix
+System.")))
+
(entry (commit "5f3f70391809f8791c55c05bd1646bc58508fa2c")
(title (en "GNU C Library upgraded")
(de "GNU-C-Bibliothek aktualisiert")
--
2.23.0
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 13:27:02 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 15:25:56 +0200
Hello!
In addition to the news entry that ‘guix pull’ will display, we may want
to publicize the issue. In particular, should we:
1. Apply for a new CVE?
2. Post an article on the blog to explain in detail what happened?
That should probably include an analysis like that at
<https://www.openwall.com/lists/oss-security/2019/10/09/4>, given
that Guix does things not entirely like Nix here.
3. Email that analysis to oss-security?
4. Push a new release?
I’m tempted to think that we should do 1 to 3, as quickly as we can.
Help welcome, in particular on #2!
As for #4, I think we should push a new release soon anyway, but maybe
not just specifically for this issue since it can be addressed simply by
upgrading.
Thoughts?
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 14:14:01 GMT) (full text, mbox, link).
Ludo',
That was swift, thanks!
IANAC++.
Ludovic Courtès 写道：
> diff --git a/nix/libstore/local-store.cc
> b/nix/libstore/local-store.cc
> index 3b08492c64..3793382361 100644
> --- a/nix/libstore/local-store.cc
> +++ b/nix/libstore/local-store.cc
> @@ -88,8 +88,9 @@ LocalStore::LocalStore(bool reserveSpace)
>
> Path perUserDir = profilesDir + "/per-user";
> createDirs(perUserDir);
> - if (chmod(perUserDir.c_str(), 01777) == -1)
> - throw SysError(format("could not set permissions on
> '%1%' to 1777") % perUserDir);
> + if (chmod(perUserDir.c_str(), 0755) == -1)
> + throw SysError(format("could not set permissions on
> '%1%' to 755")
> + % perUserDir);
>
> mode_t perm = 01775;
This is inside
if (getuid() == 0 && settings.buildUsersGroup != "") {
…
}
It's not clear to me why the second condition here is relevant,
but I don't have the big picture. Nor do I suspect I want it.
Kind regards,
T G-R
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 16:22:21 +0200
Thank you for ensuring security issues are fixed.
On Wed, Oct 16, 2019 at 12:22:33PM +0200, Ludovic Courtès wrote:
> +This is now fixed by letting @command{guix-daemon} create these directories on
> +behalf of users and removing the world-writable permissions on
> +@code{per-user}. On multi-user systems, we recommend updating the daemon now.
> +To do that, run @code{sudo guix pull} if you're on a foreign distro, or run
> +@code{sudo guix pull && sudo guix system reconfigure @dots{}} on Guix
> +System.")))
Why sudo guix pull? It should be without sudo, am I wrong?
I will translate now and submit a patch.
Regards,
Florian
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 15:17:01 GMT) (full text, mbox, link).
pelzflorian,
pelzflorian (Florian Pelz) 写道：
> Why sudo guix pull? It should be without sudo, am I wrong?
Guix on ‘foreign’ distributions uses the root profile for the
daemon by default (i.e. in guix-daemon.service).
You could change this to a regular user's profile, but that
amounts to giving this user passwordless root access.
Kind regards,
T G-R
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 17:19:22 +0200
On Wed, Oct 16, 2019 at 05:16:47PM +0200, Tobias Geerinckx-Rice wrote:
> pelzflorian (Florian Pelz) 写道：
> > Why sudo guix pull? It should be without sudo, am I wrong?
>
> Guix on ‘foreign’ distributions uses the root profile for the daemon by
> default (i.e. in guix-daemon.service).
>
Sorry for being imprecise. I meant on Guix System.
Regards,
Florian
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 15:24:01 GMT) (full text, mbox, link).
pelzflorian (Florian Pelz) 写道：
> On Wed, Oct 16, 2019 at 05:16:47PM +0200, Tobias Geerinckx-Rice
> wrote:
>> blah blah blah
>
> Sorry for being imprecise. I meant on Guix System.
Sorry for misreading, you're right that it shouldn't be needed (or
recommended IMO).
Kind regards,
T G-R
On Wed, Oct 16, 2019 at 04:22:21PM +0200, pelzflorian (Florian Pelz) wrote:
> Why sudo guix pull? It should be without sudo, am I wrong?
>
The attached patch adds a German translation. Please remove the last
sudo from the de translation too if you agree that it is wrong.
Regards,
Florian
To: bug-guix@gnu.org, Ludovic Courtès <ludo@gnu.org>,
Tobias Geerinckx-Rice <me@tobias.gr>
Cc: 37744@debbugs.gnu.org, guix-security@gnu.org
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 18:28:08 +0200
Le 16 octobre 2019 12:22:33 GMT+02:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hello!
>
>Here’s a patch that fixes the issue, partly based on what the Nix folks
>did.
>
>For the client-connecting-over-TCP case, I added special handling:
>‘set-build-options’ now passes a “user-name” property, potentially
>allowing to create ‘per-user/$USER’ at that point (like you suggested,
>Tobias.)
>
>In a cluster setup, it means that the machine that runs ‘guix-daemon’
>must see the same users as the machines where its clients run, but
>that’s basically already what we expect:
><https://hpc.guix.info/blog/2017/11/installing-guix-on-a-cluster/>.
>
>There’s one case that won’t be correctly handled: in a cluster setup,
>an
>old client talking to a new daemon won’t provide info to create
>‘per-user/$USER’, and thus ‘guix package’ & co. won’t be able to create
>the user’s profile it it doesn’t already exist. I think that’s hard to
>avoid though.
>
>Thoughts?
>
>Thanks,
>Ludo’.
We could advise people to restart the service too, with e.g. systemctl restart guix-daemon
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 16:29:02 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 17:06:01 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 19:05:44 +0200
Hi!
Thanks for your feedback Tobias, Florian, and Julien!
Taking that into account, I propose this (I’ve also changed the title to
make it hopefully clearer):
--8<---------------cut here---------------start------------->8---
(entry (commit "FIXME")
(title (en "Insecure @file{/var/guix/profiles/per-user} permissions"))
(body
(en "The default user profile, @file{~/.guix-profile}, points to
@file{/var/guix/profiles/per-user/$USER}. Until now,
@file{/var/guix/profiles/per-user} was world-writable, allowing the
@command{guix} command to create the @code{$USER} sub-directory.
On a multi-user system, this allowed a malicious user to create and populate
that @code{$USER} sub-directory for another user that had not yet logged in.
Since @code{/var/@dots{}/$USER} is in @code{$PATH}, the target user could end
up running attacker-provided code. See
@uref{https://issues.guix.gnu.org/issue/37744} for more information.
This is now fixed by letting @command{guix-daemon} create these directories on
behalf of users and removing the world-writable permissions on
@code{per-user}. On multi-user systems, we recommend updating the daemon now.
To do that, run @code{sudo guix pull} if you're on a foreign distro, or run
@code{guix pull && sudo guix system reconfigure @dots{}} on Guix System. In
both cases, make sure to restart the service afterwards, with @code{herd} or
@code{systemctl}.")))
--8<---------------cut here---------------end--------------->8---
If this is fine with you, I hereby request translation of this entry.
:-)
I’ll commit the change within a few hours if there are no objections.
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 19:51:02 GMT) (full text, mbox, link).
Ludo',
Ludovic Courtès 写道：
> Taking that into account, I propose this (I’ve also changed the
> title to
> make it hopefully clearer):
Here's my NL translation:
(nl "Onveilige
@file{/var/guix/profiles/per-user}-rechten"))
(nl "Het standaard gebruikersprofiel,
@file{~/.guix-profile}, verwijst
naar @file{/var/guix/profiles/per-user/$USER}. Tot op heden kon
om het evenwie
in @file{/var/guix/profiles/per-user} schrijven, wat het
@command{guix}-commando
toestond de @code{$USER} submap aan te maken.
Op systemen met meerdere gebuikers kon hierdoor een kwaadaardige
gebruiker een
@code{$USER} submap met inhoud aanmaken voor een andere gebruiker
die nog niet
was ingelogd. Omdat @code{/var/@dots{}/$USER} zich in
@code{$PATH} bevindt,
kon het doelwit zo code uitvoeren die door de aanvaller zelf werd
aangeleverd.
Zie @uref{https://issues.guix.gnu.org/issue/37744} voor meer
informatie.
Dit probleem is nu verholpen: schrijven door iedereen in
@code{per-user} is niet
meer toegestaan en @command{guix-daemon} maakt zelf submappen aan
namens de
gebruiker. Op systemen met meerdere gebruikers raden we aan om
@code{guix-daemon} nu bij te werken. Op Guix System kan dit met
@code{guix pull && sudo guix system reconfigure @dots{}}, op
andere distributies
met @code{sudo guix pull}. Herstart vervolgens in beide gevallen
@code{guix-daemon} met @code{herd} of @code{systemctl}.")
Kind regards,
T G-R
(nl "Onveilige @file{/var/guix/profiles/per-user}-rechten"))
(nl "Het standaard gebruikersprofiel, @file{~/.guix-profile}, verwijst
naar @file{/var/guix/profiles/per-user/$USER}. Tot op heden kon om het even wie
in @file{/var/guix/profiles/per-user} schrijven, wat het @command{guix}-commando
toestond de @code{$USER} submap aan te maken.
Op systemen met meerdere gebuikers kon hierdoor een kwaadaardige gebruiker een
@code{$USER} submap met inhoud aanmaken voor een andere gebruiker die nog niet
was ingelogd. Omdat @code{/var/@dots{}/$USER} zich in @code{$PATH} bevindt,
kon het doelwit zo code uitvoeren die door de aanvaller zelf werd aangeleverd.
Zie @uref{https://issues.guix.gnu.org/issue/37744} voor meer informatie.
Dit probleem is nu verholpen: schrijven door iedereen in @code{per-user} is niet
meer toegestaan en @command{guix-daemon} maakt zelf submappen aan namens de
gebruiker. Op systemen met meerdere gebruikers raden we aan om
@code{guix-daemon} nu bij te werken. Op Guix System kan dit met
@code{guix pull && sudo guix system reconfigure @dots{}}, op andere distributies
met @code{sudo guix pull}. Herstart vervolgens in beide gevallen
@code{guix-daemon} met @code{herd} of @code{systemctl}.")
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365
for Nix)
Date: Wed, 16 Oct 2019 21:58:39 +0200
Le Wed, 16 Oct 2019 19:05:44 +0200,
Ludovic Courtès <ludo@gnu.org> a écrit :
> Hi!
>
> Thanks for your feedback Tobias, Florian, and Julien!
>
> Taking that into account, I propose this (I’ve also changed the title
> to make it hopefully clearer):
>
> --8<---------------cut here---------------start------------->8---
> (entry (commit "FIXME")
> (title (en "Insecure @file{/var/guix/profiles/per-user}
> permissions")) (body
> (en "The default user profile, @file{~/.guix-profile},
> points to @file{/var/guix/profiles/per-user/$USER}. Until now,
> @file{/var/guix/profiles/per-user} was world-writable, allowing the
> @command{guix} command to create the @code{$USER} sub-directory.
>
> On a multi-user system, this allowed a malicious user to create and
> populate that @code{$USER} sub-directory for another user that had
> not yet logged in. Since @code{/var/@dots{}/$USER} is in
> @code{$PATH}, the target user could end up running attacker-provided
> code. See @uref{https://issues.guix.gnu.org/issue/37744} for more
> information.
>
> This is now fixed by letting @command{guix-daemon} create these
> directories on behalf of users and removing the world-writable
> permissions on @code{per-user}. On multi-user systems, we recommend
> updating the daemon now. To do that, run @code{sudo guix pull} if
> you're on a foreign distro, or run @code{guix pull && sudo guix
> system reconfigure @dots{}} on Guix System. In both cases, make sure
> to restart the service afterwards, with @code{herd} or
> @code{systemctl}."))) --8<---------------cut
> here---------------end--------------->8---
pour le français (n'hésite pas à reprendre le texte si tu trouves à
redire :)) :
titre : Permissions laxistes pour @file{/var/guix/profiles/per-user}
corps : Le profil utilisateur par défaut, @file{~/.guix-profile},
pointe vers @file{/var/guix/profiles/per-user/$USER}. Jusqu'à
maintenant, @file{/var/guix/profiles/per-user} était disponible en
écriture pour tout le monde, ce qui permettait à la commande
@command{guix} de créér le sous-répertoire @code{$USER}.
Sur un système multi-utilisateur, cela permet à un utilisateur
malveillant de créer et de remplir le sous-répertoire @code{USER} pour
n'importe quel utilisateur qui ne s'est jamais connecté. Comme
@code{/var/@dots{}/$USER} fait partie de @code{$PATH}, l'utilisateur
ciblé pouvait exécuter des programmes fournis par l'attaquant. Voir
@uref{https://issues.guix.gnu.org/issue/37744} pour plus de détails.
Cela est maintenant corrigé en laissant à @command{guix-daemon} le soin
de créer ces répertoire pour le compte des utilisateurs et en
supprimant les permissions en écriture pour tout le monde sur
@code{per-user}. Nous te recommandons de mettre à jour le démon
immédiatement. Pour cela, lance @code{sudo guix pull} si tu es sur
une distro externe ou @code{guix pull && sudo guix system reconfigure
@dots{}} sur le système Guix. Dans tous les cas, assure-toi ensuite de
redémarrer le service avec @code{herd} ou @code{systemctl}.
>
> If this is fine with you, I hereby request translation of this entry.
> :-)
>
> I’ll commit the change within a few hours if there are no objections.
>
> Ludo’.
>
>
>
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 20:02:02 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 22:01:37 +0200
Tobias Geerinckx-Rice <me@tobias.gr> skribis:
> Ludovic Courtès 写道：
>> diff --git a/nix/libstore/local-store.cc
>> b/nix/libstore/local-store.cc
>> index 3b08492c64..3793382361 100644
>> --- a/nix/libstore/local-store.cc
>> +++ b/nix/libstore/local-store.cc
>> @@ -88,8 +88,9 @@ LocalStore::LocalStore(bool reserveSpace)
>> Path perUserDir = profilesDir + "/per-user";
>> createDirs(perUserDir);
>> - if (chmod(perUserDir.c_str(), 01777) == -1)
>> - throw SysError(format("could not set permissions on
>> '%1%' to 1777") % perUserDir);
>> + if (chmod(perUserDir.c_str(), 0755) == -1)
>> + throw SysError(format("could not set permissions on
>> '%1%' to 755")
>> + % perUserDir);
>> mode_t perm = 01775;
>
> This is inside
>
> if (getuid() == 0 && settings.buildUsersGroup != "") {
> …
> }
>
> It's not clear to me why the second condition here is relevant, but I
> don't have the big picture. Nor do I suspect I want it.
Yeah ‘settings.buildUsersGroup != ""’ probably doesn’t make all that
much sense here but it was already there and we strongly discourage
against root without ‘--build-users-group’ anyway.
Thanks for having lynx eyes! :-)
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 20:29:02 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 22:28:17 +0200
Ludovic Courtès <ludo@gnu.org> skribis:
> In addition to the news entry that ‘guix pull’ will display, we may want
> to publicize the issue. In particular, should we:
>
> 1. Apply for a new CVE?
I went ahead and asked for a CVE ID via <https://cveform.mitre.org/>.
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 21:39:02 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 23:38:07 +0200
Julien Lepiller <julien@lepiller.eu> skribis:
> pour le français (n'hésite pas à reprendre le texte si tu trouves à
> redire :)) :
Pushed on your behalf, merci ! :-)
Ludo'.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 21:40:01 GMT) (full text, mbox, link).
To: "pelzflorian \(Florian Pelz\)" <pelzflorian@pelzflorian.de>
Cc: 37744@debbugs.gnu.org
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 23:39:37 +0200
Hi Florian,
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
>>From 14d4d176bae1e67c627a169c881720f3f9fb3904 Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian@pelzflorian.de>
> Date: Wed, 16 Oct 2019 16:37:27 +0200
> Subject: [PATCH] nls: Update 'de' translation of news entries.
>
> * etc/news.scm: Add new 'de' translation.
I committed this with minor changes (removed “sudo”, etc.), but the
translation corresponds to the first version of the entry. Please feel
free to commit changes directly to update it!
Thanks,
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Wed, 16 Oct 2019 21:41:03 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Wed, 16 Oct 2019 23:41:41 +0200
I pushed the fix as 81c580c8664bfeeb767e2c47ea343004e88223c7, followed
by an updated of the ‘guix’ package in
e63b31443b29b7793e73ab04798220edc6e564fc.
Thanks everyone!
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Thu, 17 Oct 2019 02:59:02 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Thu, 17 Oct 2019 04:58:20 +0200
On Wed, Oct 16, 2019 at 11:39:37PM +0200, Ludovic Courtès wrote:
> I committed this with minor changes (removed “sudo”, etc.), but the
> translation corresponds to the first version of the entry. Please feel
> free to commit changes directly to update it!
>
Oh no, it seems my message did not get through. I should not have
sent it off-list, how stupid of me.
----- Forwarded message from "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> -----
Date: Wed, 16 Oct 2019 21:00:57 +0200
From: "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>
To: Ludovic Courtès <ludo@gnu.org>
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for Nix)
User-Agent: NeoMutt/20180716
(Off-list.)
On Wed, Oct 16, 2019 at 07:05:44PM +0200, Ludovic Courtès wrote:
> If this is fine with you, I hereby request translation of this entry.
> :-)
(title
[…]
(de "Sicherheitslücke in @file{/var/guix/profiles/per-user}-Berechtigungen")
(body[…]
(de "Das voreingestellte Benutzerprofil, @file{~/.guix-profile},
verweist auf @file{/var/guix/profiles/per-user/$USER}. Bisher hatte jeder
Benutzer Schreibzugriff auf @file{/var/guix/profiles/per-user}, wodurch der
@command{guix}-Befehl berechtigt war, das Unterverzeichnis @code{$USER}
anzulegen.
Wenn mehrere Benutzer dasselbe System benutzen, kann ein böswilliger
Benutzer so das Unterverzeichnis @code{$USER} und Dateien darin für
einen anderen Benutzer anlegen, wenn sich dieser noch nie angemeldet
hat. Weil @code{/var/…/$USER} auch in @code{$PATH} aufgeführt ist,
kann der betroffene Nutzer dazu gebracht werden, vom Angreifer
vorgegebenen Code auszuführen. Siehe
@uref{https://issues.guix.gnu.org/issue/37744} für weitere
Informationen.
Der Fehler wurde nun behoben, indem @command{guix-daemon} diese
Verzeichnisse jetzt selbst anlegt statt das dem jeweiligen
Benutzerkonto zu überlassen. Der Schreibzugriff auf @code{per-user}
wird den Benutzern entzogen. Für Systeme mit mehreren Benutzern
empfehlen wir, den Daemon jetzt zu aktualisieren. Auf einer
Fremddistribution führen Sie dazu @code{sudo guix pull} aus; auf einem
Guix-System führen Sie @code{guix pull && sudo guix system reconfigure
…} aus. Achten Sie in beiden Fällen darauf, den Dienst mit @code{herd}
oder @code{systemctl} neuzustarten.")
Thank you for your important work! :)
Regards,
Florian
----- End forwarded message -----
Regards,
Florian
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Thu, 17 Oct 2019 03:02:02 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Thu, 17 Oct 2019 05:01:57 +0200
On Thu, Oct 17, 2019 at 04:58:19AM +0200, pelzflorian (Florian Pelz) wrote:
> On Wed, Oct 16, 2019 at 11:39:37PM +0200, Ludovic Courtès wrote:
> > I committed this with minor changes (removed “sudo”, etc.), but the
> > translation corresponds to the first version of the entry. Please feel
> > free to commit changes directly to update it!
> >
>
> Oh no, it seems my message did not get through. I should not have
> sent it off-list, how stupid of me.
>
Will commit now.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Thu, 17 Oct 2019 16:20:02 GMT) (full text, mbox, link).
Hi!
Ludovic Courtès <ludo@gnu.org> skribis:
> In addition to the news entry that ‘guix pull’ will display, we may want
> to publicize the issue. In particular, should we:
>
> 1. Apply for a new CVE?
>
> 2. Post an article on the blog to explain in detail what happened?
> That should probably include an analysis like that at
> <https://www.openwall.com/lists/oss-security/2019/10/09/4>, given
> that Guix does things not entirely like Nix here.
>
> 3. Email that analysis to oss-security?
>
> 4. Push a new release?
>
> I’m tempted to think that we should do 1 to 3, as quickly as we can.
> Help welcome, in particular on #2!
Attached is a draft based on ‘etc/news.scm’.
Let me know what you think!
Ludo’.
title: Insecure permissions on profile directory
date: 2019-10-05 14:30
author: Ludovic Courtès
tags: Security
---
We have become aware of a security issue for Guix on multi-user systems
[that we have just fixed](https://issues.guix.gnu.org/issue/37744).
Anyone running Guix on a multi-user system is encouraged to upgrade
`guix-daemon`—see below for instructions.
# Context
The default user profile, `~/.guix-profile`, points to
`/var/guix/profiles/per-user/$USER`. Until now,
`/var/guix/profiles/per-user` was world-writable, allowing the `guix`
command to create the `$USER` sub-directory.
On a multi-user system, this allowed a malicious user to create and
populate that `$USER` sub-directory for another user that had not yet
logged in. Since `/var/…/$USER` is in `$PATH`, the target user could
end up running attacker-provided code. See
https://issues.guix.gnu.org/issue/37744 for more information.
This issue was initially [reported by Michael Orlitzky for
Nix](https://www.openwall.com/lists/oss-security/2019/10/09/4)
([CVE-2019-17365](https://nvd.nist.gov/vuln/detail?vulnId=CVE-2019-17365)).
# Fix
The [fix](https://issues.guix.gnu.org/issue/37744) consists in letting
`guix-daemon` create these directories on behalf of users and removing
the world-writable permissions on `per-user`.
For [cluster
setups](https://hpc.guix.info/blog/2017/11/installing-guix-on-a-cluster/)
where clients connect to the daemon over TCP ([thanks to the `--listen`
option of
`guix-daemon`](https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html)),
the fix _requires_ `guix-daemon` to be able to resolve user names so
that it can create `/var/…/per-user/$USER` with the right ownership.
Note also that the `guix` command prior to this fix would not
communicate the user name it’s running under to the daemon, thereby
preventing it from creating that directory on its behalf.
# Upgrading
On multi-user systems, we recommend upgrading the daemon now.
To upgrade the daemon on a “foreign distro”, run something along these
lines:
```
sudo guix pull
sudo systemctl restart guix-daemon.service
```
On Guix System, run:
```
guix pull
sudo guix system reconfigure /etc/config.scm
sudo herd restart guix-daemon
```
Once you’ve run `guix build hello` or any other `guix` command, you
should see that `/var/guix/profiles/per-user` is no longer
world-writable:
```
$ ls -ld /var/guix/profiles/per-user
drwxr-xr-x 5 root root 4096 Jun 23 2017 /var/guix/profiles/per-user
```
Please report any issues you may have to
[`guix-devel@gnu.org`](https://guix.gnu.org/contact/). See the
[security web page](https://guix.gnu.org/security/) for information on
how to report security issues.
#### About GNU Guix
[GNU Guix](https://www.gnu.org/software/guix) is a transactional package
manager and an advanced distribution of the GNU system that [respects
user
freedom](https://www.gnu.org/distros/free-system-distribution-guidelines.html).
Guix can be used on top of any system running the kernel Linux, or it
can be used as a standalone operating system distribution for i686,
x86_64, ARMv7, and AArch64 machines.
In addition to standard package management features, Guix supports
transactional upgrades and roll-backs, unprivileged package management,
per-user profiles, and garbage collection. When used as a standalone
GNU/Linux distribution, Guix offers a declarative, stateless approach to
operating system configuration management. Guix is highly customizable
and hackable through [Guile](https://www.gnu.org/software/guile)
programming interfaces and extensions to the
[Scheme](http://schemers.org) language.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Thu, 17 Oct 2019 19:02:02 GMT) (full text, mbox, link).
Ludo',
Ludovic Courtès 写道：
> See https://issues.guix.gnu.org/issue/37744
Will this be automatically linkified?
> This issue was initially [reported by Michael Orlitzky for
> Nix](https://www.openwall.com/lists/oss-security/2019/10/09/4)
> ([CVE-2019-17365](https://nvd.nist.gov/vuln/detail?vulnId=CVE-2019-17365)).
>
> # Fix
>
> The [fix](https://issues.guix.gnu.org/issue/37744) consists in
> letting
From the Oxford Dictionaries:
1 (consist of) be composed or made up of
(consist in) have as an essential feature
TIL.
> # Upgrading
>
> On multi-user systems, we recommend upgrading the daemon now.
>
> To upgrade the daemon on a “foreign distro”, run something along
> these
Imperialist nitpick: why list the foreigners first? :-)
Anti-imperialist nitpick: reversing the two allows using ‘other
distributions’ instead of ‘foreign’ which always sounds a bit
dismissive to my ears.
End nitpick.
Thank you for taking care of this from start to finish,
T G-R
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Thu, 17 Oct 2019 22:25:58 +0200
Hallo!
Tobias Geerinckx-Rice <me@tobias.gr> skribis:
> Ludovic Courtès 写道：
>> See https://issues.guix.gnu.org/issue/37744
>
> Will this be automatically linkified?
Yes, I think so.
>> # Upgrading
>>
>> On multi-user systems, we recommend upgrading the daemon now.
>>
>> To upgrade the daemon on a “foreign distro”, run something along
>> these
>
> Imperialist nitpick: why list the foreigners first? :-)
>
> Anti-imperialist nitpick: reversing the two allows using ‘other
> distributions’ instead of ‘foreign’ which always sounds a bit
> dismissive to my ears.
>
> End nitpick.
That makes sense to me; I’m not satisfied with “foreign” either (I think
the inspiration came from FFIs, but still). Maybe “fellow distros”?
:-)
I’ve received the CVE ID (CVE-2019-18192) just now so I’ve added it to
the article and pushed it.
It should show up on line shortly.
Thank you for your feedback!
Ludo’.
Changed bug title to 'Insecure permissions on /var/guix/profiles/per-user (CVE-2019-18192)' from 'Per-user profile directory hijack (CVE-2019-17365 for Nix)'
Request was from Ludovic Courtès <ludo@gnu.org>
to control@debbugs.gnu.org.
(Thu, 17 Oct 2019 20:27:02 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Fri, 18 Oct 2019 02:22:03 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Thu, 17 Oct 2019 19:21:28 -0700
Hi Ludo, Tobias,
On +2019-10-17 22:25:58 +0200, Ludovic Courtès wrote:
> Hallo!
>
> Tobias Geerinckx-Rice <me@tobias.gr> skribis:
>
> > Ludovic Courtès 写道：
> >> See https://issues.guix.gnu.org/issue/37744
> >
> > Will this be automatically linkified?
>
> Yes, I think so.
>
> >> # Upgrading
> >>
> >> On multi-user systems, we recommend upgrading the daemon now.
> >>
> >> To upgrade the daemon on a “foreign distro”, run something along
> >> these
> >
> > Imperialist nitpick: why list the foreigners first? :-)
> >
> > Anti-imperialist nitpick: reversing the two allows using ‘other
> > distributions’ instead of ‘foreign’ which always sounds a bit
> > dismissive to my ears.
> >
> > End nitpick.
>
> That makes sense to me; I’m not satisfied with “foreign” either (I think
> the inspiration came from FFIs, but still). Maybe “fellow distros”?
> :-)
Is not the important distinction whether the "foreign distro" can be generated
with pure guix libre components using a pure guix tool chain vs not?
Maybe define a (guix-auditable? "/") test and then s/foreign/non-guix-auditable/g
in docs and discussions?
Just a thought :)
__
Regards,
Bengt Richter
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Fri, 18 Oct 2019 14:37:01 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Fri, 18 Oct 2019 16:36:30 +0200
Bengt Richter <bokr@bokr.com> skribis:
> On +2019-10-17 22:25:58 +0200, Ludovic Courtès wrote:
[...]
>> > Imperialist nitpick: why list the foreigners first? :-)
>> >
>> > Anti-imperialist nitpick: reversing the two allows using ‘other
>> > distributions’ instead of ‘foreign’ which always sounds a bit
>> > dismissive to my ears.
>> >
>> > End nitpick.
>>
>> That makes sense to me; I’m not satisfied with “foreign” either (I think
>> the inspiration came from FFIs, but still). Maybe “fellow distros”?
>> :-)
>
> Is not the important distinction whether the "foreign distro" can be generated
> with pure guix libre components using a pure guix tool chain vs not?
“Foreign distro” designates any distro other than Guix System. From a
technical viewpoint, it’s sometimes useful to be able to make that
distinction.
HTH,
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#37744; Package guix.
(Sat, 19 Oct 2019 01:33:02 GMT) (full text, mbox, link).
Subject: Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for
Nix)
Date: Fri, 18 Oct 2019 18:32:01 -0700
Hi Ludo,
On +2019-10-18 16:36:30 +0200, Ludovic Courtès wrote:
> Bengt Richter <bokr@bokr.com> skribis:
>
> > On +2019-10-17 22:25:58 +0200, Ludovic Courtès wrote:
>
> [...]
>
> >> > Imperialist nitpick: why list the foreigners first? :-)
> >> >
> >> > Anti-imperialist nitpick: reversing the two allows using ‘other
> >> > distributions’ instead of ‘foreign’ which always sounds a bit
> >> > dismissive to my ears.
> >> >
> >> > End nitpick.
> >>
> >> That makes sense to me; I’m not satisfied with “foreign” either (I think
> >> the inspiration came from FFIs, but still). Maybe “fellow distros”?
> >> :-)
> >
> > Is not the important distinction whether the "foreign distro" can be generated
> > with pure guix libre components using a pure guix tool chain vs not?
>
> “Foreign distro” designates any distro other than Guix System. From a
> technical viewpoint, it’s sometimes useful to be able to make that
> distinction.
>
> HTH,
> Ludo’.
I was trying to get to a more exact definition of "that distinction" :)
I have read the page at "info guix installation", where "foreign" is explained:
---------------------------
Note: We recommend the use of this shell installer script
(https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh)
to install Guix on top of a running GNU/Linux system, thereafter
called a “foreign distro”.(1) The script automates the download,
installation, and initial configuration of Guix. It should be run
as the root user.
When installed on a foreign distro, GNU Guix complements the
available tools without interference. Its data lives exclusively in two
directories, usually ‘/gnu/store’ and ‘/var/guix’; other files on your
system, such as ‘/etc’, are left untouched.
[...]
(1) This section is concerned with the installation of the package
manager, which can be done on top of a running GNU/Linux system. If,
instead, you want to install the complete GNU operating system, *note
System Installation::.
---------------------------
I have also read from "info guix introduction":
-----------------
(2) We used to refer to Guix System as “Guix System Distribution” or
“GuixSD”. We now consider it makes more sense to group everything under
the “Guix” banner since, after all, Guix System is readily available
through the ‘guix system’ command, even if you’re using a different
distro underneath!
----------------
further along it says:
-----------------------
With Guix System, you _declare_ all aspects of the operating system
configuration and Guix takes care of instantiating the configuration in
a transactional, reproducible, and stateless fashion (*note System
Configuration::). Guix System uses the Linux-libre kernel, the Shepherd
initialization system (*note (shepherd)Introduction::), the well-known
GNU utilities and tool chain, as well as the graphical environment or
system services of your choice.
-----------------------
That sounds more restricted than "... even if you’re using a different
distro underneath!"
When you say "Guix System," do/should you really mean _only_ a system specifically
running a linux-libre kernel, built with no dependencies outside of GuixSD
official sources, and using Shepherd initialization??
E.g., the purism OS has (UIAM) been recognized as free as in RMS's "ryf" but is it
compiled entirely using only tools in /gnu/store/... ?
Ask them, right? ;-)
(BTW, does anyone in the guix community have contact with them?
I think they are trying to contribute upstream and do "The Right Thing"(TM))
My point is, if e.g. a bug is caused by something that is different in their kernel image
from the one you generate from linux-libre and GuixSD sources, then we will be chasing a bug
in their build process, not ours.
Sometimes it might be "useful to be able to make that distinction" no? :)
(kernel image is just an example, likewise for initrd's or anything that runs that was not derived
from official guix/GuixSD sources).
BTW, Is it safe to do "guix system reconfigure" naively, "... even if you’re using a different
distro underneath!" ?? I am afraid to try it :)
--
Regards,
Bengt Richter
PS. I think it would be useful if there were a LD_IMPURE_REFERENCE_LOG="path/to/logfile.txt"
in an easy-to-edit place that, if present, would cause the ld wrapper to append to log what
it finds (even if otherwise ignoring impure refs)
WDYT?
bug archived.
Request was from Debbugs Internal Request <help-debbugs@gnu.org>
to internal_control@debbugs.gnu.org.
(Sat, 16 Nov 2019 12:24:06 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.