On Wed, 2019-04-17 at 12:39 -0400, Simo Sorce wrote:
> On Tue, 2019-04-16 at 14:11 -0700, Adam Williamson wrote:
> > On Mon, 2019-04-15 at 20:42 -0600, Chris Murphy wrote:
> > > On Mon, Apr 15, 2019 at 8:32 AM Martin Kolman <
> > > mkolman(a)redhat.com> wrote:
> > > > On Fri, 2019-04-12 at 13:33 -0600, Chris Murphy wrote:
> > > > > Hi,
> > > > >
> > > > > I ran into this "fun" hack
> > > > >
https://news.ycombinator.com/item?id=19642554 and I'm
> > > > > wondering
> > > > > whether it'd be a good idea for F31 to ship with:
> > > > >
> > > > > #AllowAgentForwarding no
> > > > > #PasswordAuthentication no
> > > > >
> > > > > Cockpit provides an interface to add SSH public keys for a
> > > > > while now.
> > > > > However the installer doesn't require creation of an admin
> > > > > user, it's
> > > > > an option.
> > > >
> > > > This is not entirely correct. During a "normal"
installation
> > > > from network or
> > > > DVD Anaconda, both interactive and kickstart Anaconda does
> > > > require to have one of:
> > > > - a root user account with password set
> > > > - a user in the wheel group
> > > > If either of those is satisfied - or both - the installation
> > > > can proceed.
> > >
> > > I set a user without "Make this user administrator" checked,
> > > and also
> > > went to root user and locked it, did not set a password. And
> > > the
> > > installer allow installation to proceed and quits without
> > > error.
> > >
> > > At the very least it would be nice if the installer made "Make
> > > this
> > > user administrator" checked by default. But ideally I'd say
> > > check it,
> > > and gray it out to indicate it's immutable. That user will be
> > > the
> > > admin. It's inappropriate for root to be the admin.
> >
> > This would be a major policy change, it is not something to just
> > randomly decide on a mailing list. (FWIW it would also break just
> > about
> > all the openQA tests, which all set a root password during
> > installation, because that's much more straightforward than
> > dealing
> > with sudo.)
>
> Especially for things like scp/rsync like for backups ... it's the
> reason why I do not disable root, as I have my backup scripts that
> go
> and fetch data from machines, and you can't really do that via
> sudo.
> (would like to be illuminated if there is a way to do that with
> rsync
> via sudo that does not involve giving fundamentally passwordless
> root
> access to a "backup" user)
(Talking about disabling root logins here, of course I use ssh keys,
not passwords)
The proposal to follow upstream would be disabling only the root
password logins so your scripts will be intact.
To actually see what and who is going to be broken by this we will
probably have to do the change itself so we should really start with
the change proposal as soon as the Fedora 30 will be out.
Regards,
--
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.