guix home cannot configure authorized_keys

  • Open
  • quality assurance status badge
Details
4 participants
  • Thiago Jung Bauermann
  • Liliana Marie Prikler
  • Maxime Devos
  • Zacchaeus Scheffer
Owner
unassigned
Submitted by
Zacchaeus Scheffer
Severity
normal
Z
Z
Zacchaeus Scheffer wrote on 3 Feb 2022 19:08
guix home symlink permissions
(address . bug-guix@gnu.org)
CAJejy7=okwP6Sous-ab_Ta44CgDDT9i795AxBcaZKyWaM8WErQ@mail.gmail.com
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: file
T
T
Thiago Jung Bauermann wrote on 3 Feb 2022 20:56
(name . Zacchaeus Scheffer)(address . zaccysc@gmail.com)(address . 53752@debbugs.gnu.org)
1737102.PxY0oXxzeL@popigai
Hello Zacchaeus,

Em quinta-feira, 3 de fevereiro de 2022, às 15:08:12 -03, Zacchaeus Scheffer
escreveu:
Toggle quote (8 lines)
> 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
Z
Z
Zacchaeus Scheffer wrote on 3 Feb 2022 22:22
(name . Thiago Jung Bauermann)(address . bauermann@kolabnow.com)(address . 53752@debbugs.gnu.org)
CAJejy7mVv5whyc3nJt3e8S+DkKyZbRdoXRNT5q-DdVdJNLfX4A@mail.gmail.com
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: file
T
T
Thiago Jung Bauermann wrote on 4 Feb 2022 00:00
control message for bug #53752
(address . control@debbugs.gnu.org)
877dabftdp.fsf@kolabnow.com
retitle 53752 guix home cannot configure authorized_keys
quit
T
T
Thiago Jung Bauermann wrote on 4 Feb 2022 00:06
Re: bug#53752: guix home symlink permissions
(name . Zacchaeus Scheffer)(address . zaccysc@gmail.com)(address . 53752@debbugs.gnu.org)
68523536.hgpfNYuzMs@popigai
Em quinta-feira, 3 de fevereiro de 2022, às 18:22:49 -03, Zacchaeus Scheffer
escreveu:
Toggle quote (12 lines)
> 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
L
L
Liliana Marie Prikler wrote on 4 Feb 2022 10:58
Re: guix home symlink permissions
af6b7c3774458e0c199f3ffc33dd6cebfc4e9ccd.camel@ist.tugraz.at
Am Donnerstag, dem 03.02.2022 um 13:08 -0500 schrieb Zacchaeus
Scheffer:
Toggle quote (7 lines)
> 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

Z
Z
Zacchaeus Scheffer wrote on 4 Feb 2022 19:17
(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)(address . 53752@debbugs.gnu.org)
CAJejy7=OcPQ17hix2uNwdPbNnTBwGc=f-3m=OF4Q+ksJWhRhPg@mail.gmail.com
Toggle quote (17 lines)
>
> > 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
Toggle quote (5 lines)
> 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...


Toggle quote (14 lines)
> 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: file
Z
Z
Zacchaeus Scheffer wrote on 7 Feb 2022 20:47
(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)(address . 53752@debbugs.gnu.org)
CAJejy7=b-fbre8P_WLkT8A797-gj=XvqTL125LN+GJ1og0CK5A@mail.gmail.com
Toggle quote (21 lines)
>
> > 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: file
M
M
Maxime Devos wrote on 7 Feb 2022 22:02
Re: bug#53752: guix home symlink permissions
(address . 53752@debbugs.gnu.org)
49b4975e6c61a7ed0010c850b52dab811e4803b7.camel@telenet.be
Zacchaeus Scheffer schreef op ma 07-02-2022 om 14:47 [-0500]:
Toggle quote (22 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYgGI4hccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7tNBAP9AUydUD7lT40Sbkf2vbmAQ6mMf
oRjqyTjzsnyRo50bYwEAtcTtaFTLNID2npaF9/jT4+x2n+6kAR+CY/Sa71LlSAM=
=F8/E
-----END PGP SIGNATURE-----


L
L
Liliana Marie Prikler wrote on 8 Feb 2022 08:01
(address . 53752@debbugs.gnu.org)
663fb5a97616a8ed1bf74f10b5ba5203f15abd61.camel@ist.tugraz.at
Am Montag, dem 07.02.2022 um 22:02 +0100 schrieb Maxime Devos:
Toggle quote (27 lines)
> 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
?