Insecure permissions on /var/guix/profiles/per-user (CVE-2019-18192)

  • Done
  • quality assurance status badge
Details
6 participants
  • Bengt Richter
  • Julien Lepiller
  • Ludovic Courtès
  • Maxim Cournoyer
  • Tobias Geerinckx-Rice
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important
L
L
Ludovic Courtès wrote on 14 Oct 2019 09:47
Per-user profile directory hijack (CVE-2019-17365 for Nix)
(address . bug-guix@gnu.org)
87o8yjsr8o.fsf@gnu.org
Hello Guix,

That the per-user profile directory is world-writable allows an attacker
to hijack code run by other users, as has been reported in the context
of Nix:


I believe it applies to Guix as well.

Nix people are tracking it here:


Looks like we’ll need to do something similar to:

Thoughts?

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 14 Oct 2019 09:54
control message for bug #37744
(address . control@debbugs.gnu.org)
87mue3sqxt.fsf@gnu.org
tags 37744 + security
quit
L
L
Ludovic Courtès wrote on 14 Oct 2019 09:54
(address . control@debbugs.gnu.org)
87lftnsqxh.fsf@gnu.org
severity 37744 important
quit
L
L
Ludovic Courtès wrote on 14 Oct 2019 09:58
Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for Nix)
(address . 37744@debbugs.gnu.org)
87blujsqq0.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (3 lines)
> 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’.
T
T
Tobias Geerinckx-Rice wrote on 14 Oct 2019 13:53
(name . Ludovic Courtès)(address . ludo@gnu.org)
87y2xno85o.fsf@nckx
Ludo',

Thanks for your report :-p

The 1777 is obviously very bad, no question. However: question:

Ludovic Courtès ???
Toggle quote (6 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2kYb8ACgkQ2Imw8BjF
STypnA/+LRcRUA15xM+hQ6XE6s9ij6GSJXtAkC9E1F7L4FYSK78WLG5cZNSrAknz
ekXbxMjotGMnPgeSnOHYD8opZUPPUvl8lqOVuToGrufyzrlyxdvUXBJnwGC4A/f1
//cd1d4lgt6MRuqMZphu4dm1qX+fRwGze6eWh5UF4pZGYfXZ2jzmPOG0/vZjGUlh
TEjxauL2X6qS2mWBIU6SZmTfYyT4R8yR2jNjvOQt0/LhIZasq+gt3RaODGLtbrn7
lQxX82R2NIr/xO0ykMWoCuSug3wcVKWJkMMLEgPPkOpxtH+MRDhPCatM3DO0MScV
OssNS4V+3wqvRVwzSbwUzo4TvaG0qtTSlWlvBro3qQAkELDzyfwQtAuh8SRS8R+4
/YFCGOtW4v7m9dnmwxklEzH7MIcbL+K4Evu65EOptqzN6MX4lGSrYR0lnJNXTw4J
dny6XP76NZp7vs7Nk0oVi9FUCqLf6pZT988sA0OCiaGRGWhZdTZ4CqUE0GMJVGSY
nM5kwe6gzfoZtcR5DPiyR1B6jQZ1MVTSBskIRR7UyEqoAQqiaHM0xpQyRIFu8voH
9sOxTdyboBGPDNlTv5rcMQHZ6wM2oyEAJPYZ4JpO+IIZKbTN+MEdexULOoEm33P9
Enm4lKsXEzm2no9eMGUdBA1ib7ZfQsuXRVRa6LpZ2G62DTY+RDc=
=mxLC
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote on 14 Oct 2019 18:37
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87sgnvp9k2.fsf@gmail.com
Hello,

Tobias Geerinckx-Rice <me@tobias.gr> writes:

Toggle quote (23 lines)
> 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
L
L
Ludovic Courtès wrote on 15 Oct 2019 14:34
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87d0eyuqzd.fsf@gnu.org
Hi!

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

Toggle quote (12 lines)
> 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’.
T
T
Tobias Geerinckx-Rice wrote on 15 Oct 2019 16:31
(name . Ludovic Courtès)(address . ludo@gnu.org)
87mue2nkrj.fsf@nckx
Ludo',

Thanks for your answer.

Ludovic Courtès ???
Toggle quote (9 lines)
>> 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.

Toggle quote (3 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2l2EwACgkQ2Imw8BjF
STzSrg//STsCmgYG7y1rrXkImrbsS3ueh522GvPjHvSEfn4WFJrxRk2VeIi9T0Ln
RY7BnOwEDoD7tLsJNH/t6RZYVTyNHpNBQr13UPQW59VMz2W32lIgpmxaiAKySZVR
quuX9nQPeKSTHT1h0bDwtiXvFbxE2pcBm+fAMNwTT1nsLiEWyw5DodaCKKo/lPCI
+o0XbJs6/klXrPyHFSOjB5xd17olKT1O/mHRx78cpW2ZxwaIN6kdO/eXONuajrUb
gb+cMcLIp8Y0MMkJuB9uPyC1gJq84SpxbcrMY2M2VuRnA4usoPs8RB2CQ9ek35wz
bWPwPpBz2unE0juh/yE9hleGBlRLBpsLQQhP/Z4Fb+mNo/SMlViWWHEbLzDRrsIX
mtlfz81nWqbMaSGMttDW3FRZnQS479Snh+SgxUI6kxnpYC12u7iJ5CCLidAxBoCr
0zx5Qjt0zOUFet4Qb70QZil2jEU3pK6WrAgD3avSEnUsjcULCgfuIXEG6YYS6nnn
fqnp9B4M6j3h46BAF6MGDZoYnQaDJn2EPt9XmIiZow1MMZtOZSX7hCInvvamVYD4
aAN96ri+yladlm3dregzrYY3S1NxyvzKWY6q28Oj1PhNV7pNHwTDJmzYLIGU5gaj
RaymzSVVbWusNygkQ14EdwdZ3ncms1Wwt+JBwrvVKbWuf1Ao9l8=
=TyMl
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 16 Oct 2019 08:57
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
8736fttby6.fsf@gnu.org
Hi Tobias,

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

Toggle quote (7 lines)
> 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’.
L
L
Ludovic Courtès wrote on 16 Oct 2019 12:22
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87tv89rnva.fsf@gnu.org
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:

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(+)

Toggle diff (34 lines)
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
L
L
Ludovic Courtès wrote on 16 Oct 2019 15:25
878spksty3.fsf@gnu.org
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
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’.
T
T
Tobias Geerinckx-Rice wrote on 16 Oct 2019 16:12
(name . Ludovic Courtès)(address . ludo@gnu.org)
87imoook2l.fsf@nckx
Ludo',

That was swift, thanks!

IANAC++.

Ludovic Courtès ???
Toggle quote (19 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2nJWIACgkQ2Imw8BjF
STwOGQ//cEyN0EMnK+iPMgVrc0DvagCDnyJ4VnVpTF0hOf+ltfPgB65/Nki+NpRP
q5ErZj9pz4oXkZT2GSwot5v8GxhKt82FBckWKVZ8Lxoi6hR7/voPHpDzLnid5TDx
XVqNaZUjvUk2jmcbD1fwozswLOma8qD7QPjoVQ9Awp0MU74JGkGW4AUUgwa8BXt1
49BhnCWpl3nh0tKYLCtyhVuK5jIk0U/dkzMXjxx6QM4GmalmnLAYDgOpTZpORmaD
1VrabVBMModfDG+8C1RWClpFrPgVRwqvmBK4Zkopomp+cXB4vDUZ1Sm3vsDMfhvO
hst4dvEeesA4npjeq+3nzFqcY1VvMkmHur1tTmrVvOJ7IbmMuyPPIWUTdixeH1OE
PJExpaJ3/X1fzVPaoOc5hXQFDOI3VXSgZwqA8K7yE1DUUtt+ZBtldKNUqWz1+Qsb
Nf7jYOYC5ftPryax9HULNlQlrW6Ak9f5rNavaHAm/zDrPLmBN0kpaBkAWrT4WTqn
2xVDgF7sroZ9RLOL6AJhfLeXsKi9KOvPshghTVv/NtBxBmlyU5/I4ZZDCcd8S55m
Q3afU41ALG1z7vsgVwz7/TkuZ1bpffmGV4n8DHhgc7EgkOJl5gBVg3IoQy+pVbUW
jw78Cdet8LgERD+c/aN4ITAJ9hysooby/nADTfEGJznfcs1S1pA=
=gjOy
-----END PGP SIGNATURE-----

P
P
pelzflorian (Florian Pelz) wrote on 16 Oct 2019 16:22
(name . Ludovic Courtès)(address . ludo@gnu.org)
20191016142221.qys2y2cb4spmwscq@pelzflorian.localdomain
Thank you for ensuring security issues are fixed.

On Wed, Oct 16, 2019 at 12:22:33PM +0200, Ludovic Court�s wrote:
Toggle quote (7 lines)
> +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
T
T
Tobias Geerinckx-Rice wrote on 16 Oct 2019 17:16
87ftjsoh40.fsf@nckx
pelzflorian,

pelzflorian (Florian Pelz) ???
Toggle quote (2 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2nNF8ACgkQ2Imw8BjF
STwTYQ//VTIaPOqmsG/HaW4zZEQ5SH2rmhfWkSTqaRmwRvol82/3/WoRyf6n4cst
OMCjTCZGX4+giq3/CPI3bMlR/faHLAR6WdIiuDvtcpz7II4Bw5aeGKIXQYyP5cYq
RepfwA0BzzN9yKu8yHxRgVUEToPcrTDwetKb5I2TbsKHdtJhKdKStXH+kjgwJekg
1ZvZswyu5oYkk02hM91TaTksMrWuLT32Ce4ia/TURPmx/PU0TrnGnnUIRqO/7S5l
ftovYwfSChfmSj64QBrt1QjCbcZHkwZWmmquyFT8m2JeNy/OQpx3r8F9zdq7LCuS
6u03enL7hVW+I6rYIBSlWULGT2PofDtarLBetYV1sgFdkk+A270uQTmzPYpNX18f
6y31BjYUCDKG9irMDgvC0l5GmbSZD+yeR2ROQb5cAIVoJauUtK2hH8dfLgimRC3X
dDpkQd3UhFSiJDXM1+zFgFfWSlK6d2+vBz1+8OZIXnqLhjlM2WZbyUeUVp1ep6qf
jSU+AUx1WEiy04begEjyrzXkrLG/K7lKmcQ6rEB9w9/tlZUz/sYINpTsTOB+uf5O
FrtIeFqb1JQMPAbEmsWKwVCqSycJ33YU/nxfwOpa+Mwt+PRs3E/HUoj/342zvrzr
JMBCXKYH8U/PhXtuz58Ub7dS3cN674uvwQjMkQeUr1h53rL8Lxo=
=BsCz
-----END PGP SIGNATURE-----

P
P
pelzflorian (Florian Pelz) wrote on 16 Oct 2019 17:19
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
20191016151922.5fanqbt6kiv4offx@pelzflorian.localdomain
On Wed, Oct 16, 2019 at 05:16:47PM +0200, Tobias Geerinckx-Rice wrote:
Toggle quote (7 lines)
> 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
T
T
Tobias Geerinckx-Rice wrote on 16 Oct 2019 17:23
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87eezcogtf.fsf@nckx
pelzflorian (Florian Pelz) ???
Toggle quote (6 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2nNdwACgkQ2Imw8BjF
STyFyxAAladP1ST+Td9ix4x2FEaIjZ44ZITbeSip50xvdIaOX65kxS7gib1Zq6xm
nRPnTSwlbq9iTOnerGUDG3s5uDcWl/AJEmhUqHC7PReDCHdRGrxbq/iWWPsXLcf7
ZFydaY0t+DW4iGa1GGPzWo/qCOpvngdh8yloImR7TOApNXljtlWNFTErwxuF9s3d
YjrZFSUIIXfxV+bmP1yePLOqAdEivAMvN5bd43Z2ufHgKNGNU1pkoQcGlondyQq7
jYv68jtaCbdVdymCHUZsChdp2RgnWLQTAYCkiBNaK5AWlxwtE9aNk6IxlFrH5T87
p10RXkz5xPOb7/464K6yXQgEr29wXSibFrHCSBvVAHisAdVw+dQJk8RcUSWdk2LY
LgJKHted2tLs0Z+trtkqGa0269+a2vCgGotBu0Sy12QfLsMjatGNdky4wsjCDbRu
ahaD3vYxhxtZav1pUBgInpdD/y5W58JpPdaNCwfJ4chtNkirb4soA2U57ffLthp7
u05BvRp+dr9YB2ZANsaIJ+SacRpPtA+MKUOL2V8zSWNVZR6YUXV84RhzbNh4puSi
1iwWky0PmyYthM8UqbEQ5TrI0D8ygZSwoBrorIezuKEsBQtZuZuuW+Bjcr6hkpAK
3TD7Am8Xoj00sQElGIDeOfUDtKS5kogsqazA0Q1lyDgFHNIxnbs=
=SOn3
-----END PGP SIGNATURE-----

P
P
pelzflorian (Florian Pelz) wrote on 16 Oct 2019 17:37
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)
20191016153756.xlnhk6axmg6tx35b@pelzflorian.localdomain
On Wed, Oct 16, 2019 at 04:22:21PM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (3 lines)
> 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
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.
---
etc/news.scm | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)

Toggle diff (45 lines)
diff --git a/etc/news.scm b/etc/news.scm
index afcf5fadaa..27130092c6 100644
--- a/etc/news.scm
+++ b/etc/news.scm
@@ -10,7 +10,8 @@
(version 0)
(entry (commit "FIXME")
- (title (en "Security issue with profiles in multi-user setups"))
+ (title (en "Security issue with profiles in multi-user setups")
+ (de "Sicherheitslücke bei Profilen in Mehrbenutzersystemen"))
(body
(en "The default user profile, @file{~/.guix-profile}, points to
@file{/var/guix/profiles/per-user/$USER}. Until now,
@@ -28,7 +29,27 @@ 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.")))
+System.")
+ (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{$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. Auf einem
+System 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{sudo guix pull && sudo guix
+system reconfigure …} aus.")))
(entry (commit "5f3f70391809f8791c55c05bd1646bc58508fa2c")
(title (en "GNU C Library upgraded")
--
2.23.0
J
J
Julien Lepiller wrote on 16 Oct 2019 18:28
AA3C1975-800B-4D2E-A260-20E9DC95D0F0@lepiller.eu
Le 16 octobre 2019 12:22:33 GMT+02:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
Toggle quote (27 lines)
>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
L
L
Ludovic Courtès wrote on 16 Oct 2019 19:05
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87ftjsk4d3.fsf@gnu.org
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):

Toggle snippet (23 lines)
(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}.")))

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’.
T
T
Tobias Geerinckx-Rice wrote on 16 Oct 2019 21:50
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)
87d0ewo4g1.fsf@nckx
Ludo',

Ludovic Courtès ???
Toggle quote (4 lines)
> 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.
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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2ndH4ACgkQ2Imw8BjF
STwonA//XCCZD5qBwQ52rNYuQy+RMveNpvfyABGciNqtnacohV/JpMhK4soEFkZc
PcRTlGbZdQqDMag0y5ZxpDCXboCaHJNr3Uv6t8UhDUY1kv6wOPXePAUlhn85YbEO
pbt6LPp0WNnw8CWkPjl1U5HT7fhiQdfV6NDtTTUKJLOVkbUMNYtkidJK9ycykXQk
o4mF+xuEVzdwibJ5bLJCSKN+3hIyFPFxOHcbGP96ocFtZeXXFki3ppkJ9Mv9OWxW
4aRl2L+7+aiQpiPytt8/RFjmzAt5uk8Ojf6l0VDMQ+8v2oJTyufp7zFHskKP6MOO
I8fqvh1RCMpBM1Ddi0Rlwke4OSFmKcDlMZZtooH4Q9Czqu/pq4/U48RlM+JRryJC
JsNMcAITRsRlLirRwzeX4XBOmTHV5OxXxMSEAss2xBgcz57AXDOQ2p7M7SNk072T
n8jVU8LvDPk51g+x3+MmnriT24NZ+2OdWyAC63HfjaAdBJqTsFcfZXp7YvNGgde3
rYNJVzjHh62dE2bzmz5riiOZ5PxayMLlLSsqVQL7gkjFr5E0ZqKncdyhnkOiq3G2
LBI618smiGKzeCYbQ4ReRJx7xC59DJbFzu6Uxxe1ItLUhGH43EM33DbTQQu32AeD
htiKQDkxv+POKHegOKwKX161mHNHUF/tPEGCCE5P7bHt+CjiDQk=
=//rT
-----END PGP SIGNATURE-----

T
T
Tobias Geerinckx-Rice wrote on 16 Oct 2019 21:55
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)
87blugo47z.fsf@nckx
Let's try that again:
(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}.")
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2ndaAACgkQ2Imw8BjF
STwCew/6AytKwVYnds0lkKGqO2ArULiXafhmJPDr+PlVFiAVFwQNhrto27e3RO03
o+KaMsxbdHln8eaGM1CfP9B63iMXIEJSSTbbO8GRZo9DzzhrE4AZXazHODURJul8
zePP+QvHReIwP4dgmSC8CrFIAWY5VdRyqGPSnxXMKNMNGllW0TEJbmZ+kTl6BLDU
YXeukCC2Sau3QsVHUHe+U+exKFDvT99CjS/rGs4BBmbRf6GPoCoTDepONg7OyCX8
ZDx8B83vFaUfZfwcg6bSy+iTzawbgERUaxCuK6KABHceWZcy3RQDUOR4cBz6lYZb
K4L1nxxZCIx16cvit5NTSaCgdT3zwfu6f5gITiJDdorvWAy8xfQSuUwojNGQmyvq
RWaux09oKQS+jSyuAN7cIqFKrEKkmC5rUsUpb7rpNdZCPvLiS9uli1zv3+LvK2KT
Rv8psze9mdiAfHnlHEtlnR11Gg7b8+R1sUad62V/erjuDtRzavLf2IFmUmvxk0jQ
CS8BJRRZs8BuuvobNCdkz295uJd7MWcoIwqjVn/N7yE6QC6hzOL4Ys6eP++6IjHa
4dU8WEj4g3oT8xUWd3ePtdtHxjTiBpAk8iM7+30WpKjlMTgWvceId1phfUxlQauQ
xfwRAf5DKosIP+QIcyYstk0KWanNYz6YkcSiMFK6Hm1ucMeLBkY=
=1dY2
-----END PGP SIGNATURE-----

J
J
Julien Lepiller wrote on 16 Oct 2019 21:58
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)
20191016215839.73c32b64@sybil.lepiller.eu
Le Wed, 16 Oct 2019 19:05:44 +0200,
Ludovic Courtès <ludo@gnu.org> a écrit :

Toggle quote (33 lines)
> 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}.

Toggle quote (10 lines)
>
> 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’.
>
>
>
L
L
Ludovic Courtès wrote on 16 Oct 2019 22:01
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87a7a0jw7y.fsf@gnu.org
Tobias Geerinckx-Rice <me@tobias.gr> skribis:

Toggle quote (27 lines)
> 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’.
L
L
Ludovic Courtès wrote on 16 Oct 2019 22:28
(address . 37744@debbugs.gnu.org)(address . guix-security@gnu.org)
875zkojuzi.fsf@gnu.org
Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (5 lines)
> 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’.
L
L
Ludovic Courtès wrote on 16 Oct 2019 23:38
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 37744@debbugs.gnu.org)
871rvcid6o.fsf@gnu.org
Julien Lepiller <julien@lepiller.eu> skribis:

Toggle quote (3 lines)
> pour le français (n'hésite pas à reprendre le texte si tu trouves à
> redire :)) :

Pushed on your behalf, merci ! :-)

Ludo'.
L
L
Ludovic Courtès wrote on 16 Oct 2019 23:39
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 37744@debbugs.gnu.org)
87wod4gyjq.fsf@gnu.org
Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (7 lines)
>>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’.
L
L
Ludovic Courtès wrote on 16 Oct 2019 23:40
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 37744@debbugs.gnu.org)
87sgnsgyiw.fsf@gnu.org
Tobias Geerinckx-Rice <me@tobias.gr> skribis:

Toggle quote (2 lines)
> Let's try that again:

Committed on your behalf, thanks! :-)
L
L
Ludovic Courtès wrote on 16 Oct 2019 23:41
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 37744-done@debbugs.gnu.org)
87o8yggyga.fsf@gnu.org
I pushed the fix as 81c580c8664bfeeb767e2c47ea343004e88223c7, followed
by an updated of the ‘guix’ package in
e63b31443b29b7793e73ab04798220edc6e564fc.

Thanks everyone!

Ludo’.
Closed
P
P
pelzflorian (Florian Pelz) wrote on 17 Oct 2019 04:58
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)
20191017025819.ptdeqtscgphvqyw7@pelzflorian.localdomain
On Wed, Oct 16, 2019 at 11:39:37PM +0200, Ludovic Courtès wrote:
Toggle quote (5 lines)
> 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:
Toggle quote (4 lines)
> 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
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
P
P
pelzflorian (Florian Pelz) wrote on 17 Oct 2019 05:01
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)
20191017030157.rriyxhdkhhjvalyd@pelzflorian.localdomain
On Thu, Oct 17, 2019 at 04:58:19AM +0200, pelzflorian (Florian Pelz) wrote:
Toggle quote (10 lines)
> 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.
L
L
Ludovic Courtès wrote on 17 Oct 2019 18:18
(address . 37744@debbugs.gnu.org)(address . guix-security@gnu.org)
87blufny52.fsf@gnu.org
Hi!

Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (17 lines)
> 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
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

This issue was initially [reported by Michael Orlitzky for

# 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
where clients connect to the daemon over TCP ([thanks to the `--listen`
option of
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
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.
T
T
Tobias Geerinckx-Rice wrote on 17 Oct 2019 21:01
(address . 37744@debbugs.gnu.org)
878spjnqlo.fsf@nckx
Ludo',

Ludovic Courtès ???
Toggle quote (2 lines)
Will this be automatically linkified?

Toggle quote (9 lines)
> 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.

Toggle quote (7 lines)
> # 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfo+u0AlEeO9y5k0W2Imw8BjFSTwFAl2oupMACgkQ2Imw8BjF
STwaxhAAjusdMbOJkvFyVQRbL9WRxA17CLUOQ0zuvtTqhnv4kB7Osfw75HD2qDa4
ViAGCUAma4Z6D+i585YFKB98dI8Zx22wgJnLDb+ZT29mDsxRzEKOESx3aPHidUY7
Lq2aV26cDPbWMDdSkKs8/bgHSv3q1TnNmYSYfx82OPwglNqP9c1BXMQavHOvod1M
haS7/PJJqBn284m/RI46p4KvqvxWWQMqs5gPSOedYTE1pZ73xqSMmP+daxrT4Oy+
8mdQvZyvk020ANdu5o/6cKLpqyCei08CriXOKm4IaZeIvYtpVmQ/mzfqNUetEvZD
SAtEhLFkMMO7dqsWI2AZPj7ficQfiy9MpX8e2SiIiaAJoOdHs4Jo2BgEnCUhufMY
CIAL9mNtCSjMUjBvWWwb2aaTrg9EargEeXcNjKevgJhm0c3kQ8cNgLlEjmukkZPk
07GQxuvqNO9aSNUY2Ulro08zU1+vzFDtTAGk6t+AgiYXYUQc0jV3BLq8n0Eln7Xw
U4X7tdHQ8VRPIkZ7qnutM5UxOSqizU80KPAzzldaFJjA9wsWpZPFrx7bmuEzepuc
znR4hRXX9cFcoouVrucVT0FsVWmCFLUfT9U4fbAg6E2a1xBPiyobUMFU7hA9Yc+x
Z+Us7hX/7hWRIrSn3gT/xnu+EyISHrlnwsUOKrawLZgUWg2C6Nk=
=XkaC
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 17 Oct 2019 22:25
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 37744@debbugs.gnu.org)
87k193ktk9.fsf@gnu.org
Hallo!

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

Toggle quote (5 lines)
> Ludovic Courtès ???
>> See https://issues.guix.gnu.org/issue/37744
>
> Will this be automatically linkified?

Yes, I think so.

Toggle quote (15 lines)
>> # 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’.
L
L
Ludovic Courtès wrote on 17 Oct 2019 22:26
control message for bug #37744
(address . control@debbugs.gnu.org)
87imonktjo.fsf@gnu.org
retitle 37744 Insecure permissions on /var/guix/profiles/per-user (CVE-2019-18192)
quit
B
B
Bengt Richter wrote on 18 Oct 2019 04:21
Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for Nix)
(name . Ludovic Courtès)(address . ludo@gnu.org)
20191018022128.GA1765@PhantoNv4ArchGx.localdomain
Hi Ludo, Tobias,

On +2019-10-17 22:25:58 +0200, Ludovic Courtès wrote:
Toggle quote (30 lines)
> 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
L
L
Ludovic Courtès wrote on 18 Oct 2019 16:36
(name . Bengt Richter)(address . bokr@bokr.com)
877e5215ox.fsf@gnu.org
Bengt Richter <bokr@bokr.com> skribis:

Toggle quote (2 lines)
> On +2019-10-17 22:25:58 +0200, Ludovic Courtès wrote:

[...]

Toggle quote (15 lines)
>> > 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’.
B
B
Bengt Richter wrote on 19 Oct 2019 03:32
(name . Ludovic Courtès)(address . ludo@gnu.org)
20191018224519.GA81713@PhantoNv4ArchGx.localdomain
Hi Ludo,

On +2019-10-18 16:36:30 +0200, Ludovic Courtès wrote:
Toggle quote (28 lines)
> 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
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?
?
Your comment

This issue is archived.

To comment on this conversation send an email to 37744@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 37744
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch