all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Zacchaeus Scheffer <zaccysc@gmail.com>
To: Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>
Cc: 53752@debbugs.gnu.org
Subject: bug#53752: guix home symlink permissions
Date: Fri, 4 Feb 2022 13:17:54 -0500	[thread overview]
Message-ID: <CAJejy7=OcPQ17hix2uNwdPbNnTBwGc=f-3m=OF4Q+ksJWhRhPg@mail.gmail.com> (raw)
In-Reply-To: <af6b7c3774458e0c199f3ffc33dd6cebfc4e9ccd.camel@ist.tugraz.at>

[-- 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 --]

  reply	other threads:[~2022-02-04 18:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-03 18:08 bug#53752: guix home symlink permissions Zacchaeus Scheffer
2022-02-03 19:56 ` Thiago Jung Bauermann via Bug reports for GNU Guix
2022-02-03 21:22   ` Zacchaeus Scheffer
2022-02-03 23:06     ` Thiago Jung Bauermann via Bug reports for GNU Guix
2022-02-04  9:58 ` Liliana Marie Prikler
2022-02-04 18:17   ` Zacchaeus Scheffer [this message]
2022-02-07 19:47     ` Zacchaeus Scheffer
2022-02-07 21:02       ` Maxime Devos
2022-02-08  7:01         ` Liliana Marie Prikler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJejy7=OcPQ17hix2uNwdPbNnTBwGc=f-3m=OF4Q+ksJWhRhPg@mail.gmail.com' \
    --to=zaccysc@gmail.com \
    --cc=53752@debbugs.gnu.org \
    --cc=liliana.prikler@ist.tugraz.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.