unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
To: Christopher Lemmer Webber <cwebber@dustycloud.org>
Cc: maxim.cournoyer@gmail.com, 44808@debbugs.gnu.org
Subject: bug#44808: Default to allowing password authentication on leaves users vulnerable
Date: Mon, 07 Dec 2020 20:53:59 +0100	[thread overview]
Message-ID: <871rg1e6js.fsf@web.de> (raw)
In-Reply-To: <87sg8hlfyu.fsf@dustycloud.org>

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


Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Dr. Arne Babenhauserheide writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>>>> #2 is more thorough but also more risky: people could find themselves
>>>>> locked out of their server after reconfiguration, though this could be
>>>>> mitigated by a news entry.
>>>>>
>>>>> Thoughts?
>>
>> My thoughts are that there is no mitigation for being locked out of a
>> pre-existing server. Keep in mind that that server might not actually be
>> accessible in any other way — it might be with a cheap hoster whose
>> support is practically non-existent, or it might be in a sealed
>> measurement container that can only be accessed via SSH without
>> disassembly.
>>
>>>> We could also do a combination of the above, as a transitional plan:
>>>> do #1 for now, but try to advertise that in the future, the default will
>>>> be changing... please explicitly set password access to #t if you need
>>>> this!  Then in the *following* release, change the default.
>>
>> This sounds like trying to retroactively fixing a problem at the wrong
>> place: If the installer creates a configuration which prevents
>> password-authentication, there is no problem for new systems and new
>> users who need password-authentication will explicitly see in the
>> config, that they have to change it, otherwise it won’t work. All the
>> while old systems will keep working.
>>
>> I do need to access my system via password+ssh from time to time,
>> because I don’t want to have a key that can access my system on a
>> presentation-laptop that (due to being moved regularly) is much less
>> secure than the fixed system. If someone gets access to the laptop and
>> compromises my keys, they can run much more efficient attacks against
>> its ssh-keys' password than the attacks people can use to attack ssh via
>> internet.
>>
>> Changing a default (an invisible setting) in a way that prevents access
>> is a serious disruption.
>>
>> In short: please don’t break running systems on update.
>>
>> Best wishes,
>> Arne
>
> It's a serious concern.  We are left in a tough bind: leave users with
> an insecure default but try to inform them as much as we can of a
> changing default, or possibly lock them out if they don't notice.
>
> Still, now feels like to me the ideal time to do it.  The number of
> people running GuixSD on servers is comparatively small.  I expect that
> to change.  It would be better to make this change sooner than later.

If the installer and the configuration examples are changed now, then
the number of people who unknowingly run Guix on an insecure
configuration should not rise.

To nudge them to secure their system, guix system reconfigure could emit
a warning that this is a potential security risk that requires setting
an explicit value (password yes or no) to silence.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

  reply	other threads:[~2020-12-07 19:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-22 23:20 bug#44808: Default to allowing password authentication on leaves users vulnerable Christopher Lemmer Webber
2020-11-23  2:32 ` Taylan Kammer
2020-11-23  3:46   ` raingloom
2020-11-23 16:15     ` Christopher Lemmer Webber
2020-11-23  3:57 ` Carlo Zancanaro
2020-11-23 16:17   ` Christopher Lemmer Webber
2020-11-30  3:58     ` Maxim Cournoyer
2020-12-05 15:14       ` Ludovic Courtès
2020-12-05 18:22         ` Christopher Lemmer Webber
2020-12-07 11:51           ` Ludovic Courtès
2020-12-07 12:56             ` Dr. Arne Babenhauserheide
2020-12-07 16:48               ` Christopher Lemmer Webber
2020-12-07 19:53                 ` Dr. Arne Babenhauserheide [this message]
2020-12-07 22:57                   ` Mark H Weaver
2020-12-08 10:36                     ` Ludovic Courtès
2020-12-09  1:31                       ` Mark H Weaver
2020-12-10  8:17                         ` Ludovic Courtès
2020-12-11  1:43                           ` Mark H Weaver
2020-12-11 18:10                             ` Ludovic Courtès
2020-12-08 13:48                     ` Christopher Lemmer Webber
2020-12-07 19:40           ` Leo Famulari
2020-12-07 21:38             ` Christopher Lemmer Webber
2021-02-11  7:46 ` raid5atemyhomework via Bug reports for GNU Guix
2021-02-11 20:36   ` Leo Famulari

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=871rg1e6js.fsf@web.de \
    --to=arne_bab@web.de \
    --cc=44808@debbugs.gnu.org \
    --cc=cwebber@dustycloud.org \
    --cc=maxim.cournoyer@gmail.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).