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

Done

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

Ludovic Courtès wrote on 14 Oct 2019 09:47

Per-user profile directory hijack (CVE-2019-17365 for Nix)

Recipients:(address . bug-guix@gnu.org)

Message-ID: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:

https://www.openwall.com/lists/oss-security/2019/10/09/4

I believe it applies to Guix as well.

Nix people are tracking it here:

https://github.com/NixOS/nix/pull/3134

https://github.com/NixOS/nix/issues/509

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

https://github.com/NixOS/nix/pull/3136/commits/5a303093dcae1e5ce9212616ef18f2ca51020b0d.

Thoughts?

Thanks,

Ludo’.

Ludovic Courtès wrote on 14 Oct 2019 09:54

control message for bug #37744

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87mue3sqxt.fsf@gnu.org

tags 37744 + security

quit

Ludovic Courtès wrote on 14 Oct 2019 09:54

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87lftnsqxh.fsf@gnu.org

severity 37744 important

quit

Ludovic Courtès wrote on 14 Oct 2019 09:58

Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for Nix)

Recipients:(address . 37744@debbugs.gnu.org)

Message-ID: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’.

Tobias Geerinckx-Rice wrote on 14 Oct 2019 13:53

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID: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

Maxim Cournoyer wrote on 14 Oct 2019 18:37

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)

Message-ID: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

Ludovic Courtès wrote on 15 Oct 2019 14:34

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)

Message-ID: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’.

Tobias Geerinckx-Rice wrote on 15 Oct 2019 16:31

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID: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

Ludovic Courtès wrote on 16 Oct 2019 08:57

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)

Message-ID: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’.

Ludovic Courtès wrote on 16 Oct 2019 12:22

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)

Message-ID: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:

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’.

Attachment: 0001-daemon-Make-profiles-per-user-non-world-writable.patch

From 07126db581f1854a2235c271fcdaecfb36705d5c Mon Sep 17 00:00:00 2001

/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

Ludovic Courtès wrote on 16 Oct 2019 15:25

Recipients:

Message-ID: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

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’.

Tobias Geerinckx-Rice wrote on 16 Oct 2019 16:12

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID: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

pelzflorian (Florian Pelz) wrote on 16 Oct 2019 16:22

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID: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

Tobias Geerinckx-Rice wrote on 16 Oct 2019 17:16

Recipients:

Message-ID: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

pelzflorian (Florian Pelz) wrote on 16 Oct 2019 17:19

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)

Message-ID: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

Tobias Geerinckx-Rice wrote on 16 Oct 2019 17:23

Recipients:(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)

Message-ID: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

pelzflorian (Florian Pelz) wrote on 16 Oct 2019 17:37

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)

Message-ID: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

* 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

Julien Lepiller wrote on 16 Oct 2019 18:28

Recipients:

Message-ID: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

Ludovic Courtès wrote on 16 Oct 2019 19:05

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)

Message-ID: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’.

Tobias Geerinckx-Rice wrote on 16 Oct 2019 21:50

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)

Message-ID: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.
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

Tobias Geerinckx-Rice wrote on 16 Oct 2019 21:55

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)

Message-ID: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}.")

Julien Lepiller wrote on 16 Oct 2019 21:58

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)

Message-ID: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’.
> 
> 
>

Ludovic Courtès wrote on 16 Oct 2019 22:01

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)

Message-ID: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’.

Ludovic Courtès wrote on 16 Oct 2019 22:28

Recipients:(address . 37744@debbugs.gnu.org)(address . guix-security@gnu.org)

Message-ID: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’.

Ludovic Courtès wrote on 16 Oct 2019 23:38

Recipients:(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 37744@debbugs.gnu.org)

Message-ID: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'.

Ludovic Courtès wrote on 16 Oct 2019 23:39

Recipients:(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 37744@debbugs.gnu.org)

Message-ID: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’.

Ludovic Courtès wrote on 16 Oct 2019 23:40

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 37744@debbugs.gnu.org)

Message-ID: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! :-)

Ludovic Courtès wrote on 16 Oct 2019 23:41

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 37744-done@debbugs.gnu.org)

Message-ID:87o8yggyga.fsf@gnu.org

I pushed the fix as 81c580c8664bfeeb767e2c47ea343004e88223c7, followed

by an updated of the ‘guix’ package in

e63b31443b29b7793e73ab04798220edc6e564fc.

Thanks everyone!

Ludo’.

Closed

pelzflorian (Florian Pelz) wrote on 17 Oct 2019 04:58

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)

Message-ID: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> -----

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

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

@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

pelzflorian (Florian Pelz) wrote on 17 Oct 2019 05:01

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37744@debbugs.gnu.org)

Message-ID: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.

Ludovic Courtès wrote on 17 Oct 2019 18:18

Recipients:(address . 37744@debbugs.gnu.org)(address . guix-security@gnu.org)

Message-ID: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

[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/37744for 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.

Tobias Geerinckx-Rice wrote on 17 Oct 2019 21:01

Recipients:(address . 37744@debbugs.gnu.org)

Message-ID:878spjnqlo.fsf@nckx

Ludo',

Ludovic Courtès ???

Toggle quote (2 lines)

> See https://issues.guix.gnu.org/issue/37744

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

Ludovic Courtès wrote on 17 Oct 2019 22:25

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 37744@debbugs.gnu.org)

Message-ID: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’.

Ludovic Courtès wrote on 17 Oct 2019 22:26

control message for bug #37744

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87imonktjo.fsf@gnu.org

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

quit

Bengt Richter wrote on 18 Oct 2019 04:21

Re: bug#37744: Per-user profile directory hijack (CVE-2019-17365 for Nix)

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID: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

Ludovic Courtès wrote on 18 Oct 2019 16:36

Recipients:(name . Bengt Richter)(address . bokr@bokr.com)

Message-ID: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’.

Bengt Richter wrote on 19 Oct 2019 03:32

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID: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

(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?

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

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date