bug#53752: guix home symlink permissions

bug#53752: guix home symlink permissions

[Zacchaeus Scheffer]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

I finally migrated my home configuration to guix home.  However, it seems
guix home creates all symlinks with 777 permissions.  This causes problems
with openssh as it will not recognize my ~/.ssh/authorized_keys.  It seems
the directories have reasonable permissions (maybe because they already
existed?), but it seems like someone could in theory edit the symlinks
in-place (though I wasn't able to figure that out).

I formulated based on the example in Section 11.1 of the devel user
manual.  You should be able to recreate the problem with (replacing <your
ssh public key here>):

(home-environment
  (services
    (list
      (simple-service
       'my-home-files-service
       home-files-service-type
       (list
         `("ssh/authorized_keys"
            ,(plain-file
               "home-authorized-keys"
               "<your ssh public key here>")))))))

[-- Attachment #2: Type: text/html, Size: 1114 bytes --]

bug#53752: guix home symlink permissions

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hello Zacchaeus,

Em quinta-feira, 3 de fevereiro de 2022, às 15:08:12 -03, Zacchaeus Scheffer 
escreveu:
> I finally migrated my home configuration to guix home.  However, it seems
> guix home creates all symlinks with 777 permissions.  This causes
> problems with openssh as it will not recognize my
> ~/.ssh/authorized_keys.  It seems the directories have reasonable
> permissions (maybe because they already existed?), but it seems like
> someone could in theory edit the symlinks in-place (though I wasn't able
> to figure that out).

In Linux, symlink permissions are meaningless. From the chmod(1) man page:

“chmod never changes the permissions of symbolic links; the chmod system 
call cannot change their permissions.  This is not a problem since the 
permissions of symbolic links are never used.  However,  for  each symbolic 
link listed on the command line, chmod changes the permissions of the 
pointed-to file.  In contrast, chmod ignores symbolic links encountered 
during recursive directory traversals.”

So AFAIK there’s nothing that guix home can do about that.
I don’t know what that implies for OpenSSH and authorized_keys, though.

-- 
Thanks,
Thiago

bug#53752: guix home symlink permissions

[Zacchaeus Scheffer]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

It seems the permissions on the symlink don't matter.  The problem is that
the file linked to in the store is readable by everyone (which I am ok with
because it's just public keys).

There is a solution with guix system by configuring openssh directly (see
openssh-configuration -> authorized-keys), but there really should be a way
to do this with guix home.  (anyone that can call guix home for my user can
see/modify my authorized_keys anyway)

Maybe this bug should be renamed to something like "guix home cannot
configure authorized_keys"?

[-- Attachment #2: Type: text/html, Size: 639 bytes --]

bug#53752: guix home symlink permissions

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Em quinta-feira, 3 de fevereiro de 2022, às 18:22:49 -03, Zacchaeus Scheffer 
escreveu:
> It seems the permissions on the symlink don't matter.  The problem is
> that the file linked to in the store is readable by everyone (which I am
> ok with because it's just public keys).
> 
> There is a solution with guix system by configuring openssh directly (see
> openssh-configuration -> authorized-keys), but there really should be a
> way to do this with guix home.  (anyone that can call guix home for my
> user can see/modify my authorized_keys anyway)
> 
> Maybe this bug should be renamed to something like "guix home cannot
> configure authorized_keys"?

Good idea. I just made that change.

I don’t use Guix Home and I don’t know much about its internals, so 
unfortunately I can’t help much with this problem.

-- 
Thanks,
Thiago

bug#53752: guix home symlink permissions

[Liliana Marie Prikler]

Am Donnerstag, dem 03.02.2022 um 13:08 -0500 schrieb Zacchaeus
Scheffer:
> I finally migrated my home configuration to guix home.  However, it
> seems guix home creates all symlinks with 777 permissions.  This causes
> problems with openssh as it will not recognize my
> ~/.ssh/authorized_keys.  It seems the directories have reasonable
> permissions (maybe because they already existed?), but it seems like
> someone could in theory edit the symlinks in-place (though I wasn't
> able to figure that out).
Instead of using symllinks for ~/.ssh/authorized_keys, you could try to
write a home-activation-service, which

1. creates ~/.ssh with chmod 700
1a. if it already existed, enforces chmod 700 anyways
2. creates authorized_keys with chmod 600 if it doesn't exist
3. writes the authorized keys.

I would strongly advise against that however.  While user homes are by
default 700 in Guix, the store is world readable and so are your
authorized keys if you put them there.  A malicious user can't
necessarily change them, but they can spy on you.

Guix currently has no way of securely storing your data in the store
(in a cryptographic sense).  This is exacerbated by the fact that such
files aren't well-encrypted by default -- user read-only is "good
enough" in many cases, e.g. gnome-keyring does encrypt passwords, but
stores metadata in plain.  Emacs plstores and Recfiles likewise support
partial encryption based on GPG.

This issue has been known since June 2020 [1].  While there would in
theory exist solutions that can work for (guix home) but not (guix
system), I can not yet make any statements regarding their quality. 
Indeed, storing secrets with Guix is an open issue, that will likely be
given some attention during the upcoming Guix Days.

Cheers

[1] https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00091.html

bug#53752: guix home symlink permissions

[Zacchaeus Scheffer]

[-- Attachment #1: Type: text/plain, Size: 2885 bytes --]

>
> > I finally migrated my home configuration to guix home.  However, it
> > seems guix home creates all symlinks with 777 permissions.  This causes
> > problems with openssh as it will not recognize my
> > ~/.ssh/authorized_keys.  It seems the directories have reasonable
> > permissions (maybe because they already existed?), but it seems like
> > someone could in theory edit the symlinks in-place (though I wasn't
> > able to figure that out).
> Instead of using symllinks for ~/.ssh/authorized_keys, you could try to
> write a home-activation-service, which
>
> 1. creates ~/.ssh with chmod 700
> 1a. if it already existed, enforces chmod 700 anyways
> 2. creates authorized_keys with chmod 600 if it doesn't exist
> 3. writes the authorized keys.
>

I'll try that soon (next 1-3 days), and hopefully then we can close this
issue.

I would strongly advise against that however.  While user homes are by
> default 700 in Guix, the store is world readable and so are your
> authorized keys if you put them there.  A malicious user can't
> necessarily change them, but they can spy on you.
>

For context, I keep such info in my password store, but am ok with certain
things from it not being "secret".  It is already standard for public keys
to be kept in the store; see:
 - operating-system -> services -> openssh -> authorized-keys
and as a more extreme example, encrypted user passwords are often kept in
the store; see:
 - operating-system -> users -> user -> password
It's not ideal that someone can snoop my public keys, but that is worth
enabling me to have private keys that can reproducibly connect to my user.
If one is worried about it, they could avoid usage of those specific
private keys as much as possible, so I think it's ok...


> Guix currently has no way of securely storing your data in the store
> (in a cryptographic sense).  This is exacerbated by the fact that such
> files aren't well-encrypted by default -- user read-only is "good
> enough" in many cases, e.g. gnome-keyring does encrypt passwords, but
> stores metadata in plain.  Emacs plstores and Recfiles likewise support
> partial encryption based on GPG.
>
> This issue has been known since June 2020 [1].  While there would in
> theory exist solutions that can work for (guix home) but not (guix
> system), I can not yet make any statements regarding their quality.
> Indeed, storing secrets with Guix is an open issue, that will likely be
> given some attention during the upcoming Guix Days.
>

At the end of the day, there will be setup that should NOT happen
automatically (should require gpg passphrase input).  Currently, I do this
for private keys by automatically pulling from my password store
(requiring password input) using fancy emacs org tangling.  I'll look
into managing even this with guix home, but that is probably a discussion
for guix-devel.

Thanks all,
Zacchaeus Scheffer

[-- Attachment #2: Type: text/html, Size: 3726 bytes --]

bug#53752: guix home symlink permissions

[Zacchaeus Scheffer]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

>
> > I finally migrated my home configuration to guix home.  However, it
>> > seems guix home creates all symlinks with 777 permissions.  This causes
>> > problems with openssh as it will not recognize my
>> > ~/.ssh/authorized_keys.  It seems the directories have reasonable
>> > permissions (maybe because they already existed?), but it seems like
>> > someone could in theory edit the symlinks in-place (though I wasn't
>> > able to figure that out).
>> Instead of using symllinks for ~/.ssh/authorized_keys, you could try to
>> write a home-activation-service, which
>>
>> 1. creates ~/.ssh with chmod 700
>> 1a. if it already existed, enforces chmod 700 anyways
>> 2. creates authorized_keys with chmod 600 if it doesn't exist
>> 3. writes the authorized keys.
>>
>
> I'll try that soon (next 1-3 days), and hopefully then we can close this
> issue.
>

I was able create the desired effect with the following service definition:
(simple-service
 'my-activation-service
 home-activation-service-type
 (gexp
  (begin
    (chdir (ungexp user-home))
    (if (not (file-exists? ".ssh"))
        (mkdir ".ssh"))
    (chmod ".ssh" #o700)
    (chdir ".ssh")
    (let ((port (open-output-file "authorized_keys")))
      (display (ungexp authorized-keys) port)
      (close-port port))
    (chmod "authorized_keys" #o600)
    (chdir ".."))))
where 'user-home and 'authorized-keys are appropriate strings defined
earlier in the file.

I believe that resolves the issue,
Zacchaeus Scheffer

[-- Attachment #2: Type: text/html, Size: 2247 bytes --]

bug#53752: guix home symlink permissions

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

Zacchaeus Scheffer schreef op ma 07-02-2022 om 14:47 [-0500]:
> I was able create the desired effect with the following service
> definition:
> (simple-service
>  'my-activation-service
>  home-activation-service-type
>  (gexp
>   (begin
>     (chdir (ungexp user-home))
>     (if (not (file-exists? ".ssh"))
>         (mkdir ".ssh"))
>     (chmod ".ssh" #o700)
>     (chdir ".ssh")
>     (let ((port (open-output-file "authorized_keys")))
>       (display (ungexp authorized-keys) port)
>       (close-port port))
>     (chmod "authorized_keys" #o600)
>     (chdir ".."))))
> where 'user-home and 'authorized-keys are appropriate strings defined
> earlier in the file.
> 
> I believe that resolves the issue,

Users shouldn't have to do this (relatively) huge block of relatively
inscrutable code though, I believe something along these lines (or a
different solution) needs to be implemented in Guix itself somewhere
before the issue is resolved.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#53752: guix home symlink permissions

[Liliana Marie Prikler]

Am Montag, dem 07.02.2022 um 22:02 +0100 schrieb Maxime Devos:
> Zacchaeus Scheffer schreef op ma 07-02-2022 om 14:47 [-0500]:
> > I was able create the desired effect with the following service
> > definition:
> > (simple-service
> >  'my-activation-service
> >  home-activation-service-type
> >  (gexp
> >   (begin
> >     (chdir (ungexp user-home))
> >     (if (not (file-exists? ".ssh"))
> >         (mkdir ".ssh"))
> >     (chmod ".ssh" #o700)
> >     (chdir ".ssh")
> >     (let ((port (open-output-file "authorized_keys")))
> >       (display (ungexp authorized-keys) port)
> >       (close-port port))
> >     (chmod "authorized_keys" #o600)
> >     (chdir ".."))))
> > where 'user-home and 'authorized-keys are appropriate strings
> > defined earlier in the file.
> > 
> > I believe that resolves the issue,
> 
> Users shouldn't have to do this (relatively) huge block of relatively
> inscrutable code though, I believe something along these lines (or a
> different solution) needs to be implemented in Guix itself somewhere
> before the issue is resolved.
I'll again be pointing at the "don't put secrets into your store"
shield.  We'd have to find a reasonable way of encrypting sensitive
data before we can do a home-ssh-service-type.

@Zacchaeus, your code can likely be simplified to
#~(with-directory-excursion #$user-home
    (mkdir-p ".ssh")
    (chmod ".ssh" #o700)
    (with-directory-excursion ".ssh"
      (copy-file #$authorized-keys "authorized_keys")
      (chmod "authorized_keys" #o600)))
though perhaps there's some magic incantation to import (guix build
utils) for mkdir-p and with-directory-excursion that I'm missing here.

Cheers