F21 System Wide Change: The securetty file is empty by default

[Simo Sorce]

On Tue, 2014-04-15 at 13:48 +0930, William Brown wrote:
> On Mon, 2014-04-14 at 23:57 -0400, Simo Sorce wrote:
> > On Tue, 2014-04-15 at 08:49 +0700, Michel Alexandre Salim wrote:
> > > On 04/14/2014 09:21 PM, Andrew Lutomirski wrote:
> > > > On Mon, Apr 14, 2014 at 6:50 AM, Michel Alexandre Salim
> > > > <salimma at fedoraproject.org> wrote:
> > > >> Apologies for being late to the discussion as well - just wanted to note
> > > >> that I've been running root-password-less configurations for some time
> > > >> (by using passwd -l to lock out the root account post-install), and
> > > >> later encountered this scenario whereby one of the disks failed fsck and
> > > >> I was dropped into a single-user mode login for maintenance, where I was
> > > >> prompted for... you get it, the root password.
> > > >>
> > > >> Resorted to rebooting and disabling fsck from grub, but how to handle
> > > >> fsck errors should probably be considered as part of this proposed change.
> > > > 
> > > > You're not the only one:
> > > > 
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1045574
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1087528
> > > > 
> > > Well, the "fastboot" flag in Grub works as a workaround, my problem is
> > > different from those that lost their root password -- I intentionally
> > > didn't set one, and expected tasks that in the past required the use of
> > > the root password to be doable by the user account nominated to be
> > > administrators, whether through %wheel membership or pkcon or other means.
> > > 
> > > > but I don't think that this is really related to securetty.
> > > > 
> > > If the use of root account is to be further discouraged, I'm pointing
> > > out that workflows that currently require it have to be revised as well.
> > 
> > I do not think it makes any sense to lock the root account.
> > 
> > It is perfectly sane to discourage from using root for day to day
> > operation and avoid or even disallow to login into the display manager
> > with root.
> > 
> > But disabling it has no useful purpose, you are just going to make
> > another account all powerful to compensate, either by giving sudo powers
> > or other similar mechanism, what you loose is the ability to properly
> > recover a system.
> > 
> > I am not saying you shouldn't be allowed to do passwd -l, but that
> > should not be mandated by the system configuration, purely a choice of
> > individual admins.
> > 
> > Simo.
> > 
> > -- 
> > Simo Sorce * Red Hat, Inc * New York
> > 
> 
> 
> If you could enter the rescue.target with a username/password instead of
> just "enter the password for root" I wouldn't mind a default locked root
> account. 

What user ?
In most of my systems there is only root locally, every other user that
can authenticate comes from LDAP which is not accessible at rescue time.

> Yes, you would have an account that would need at least ALL command
> access in sudo. For the rescue.target you could attempt to start sssd
> perhaps if you wanted to access network based accounts ...

Why ? sssd may simply be the component at fault here.

> You also don't lose that ability to recover a system anyway. Because you
> can then use physical access and init=/bin/bash if you really got
> desperate.

Sure if you have physical access everything is easier, on a colocated
machine that has only serial line access though, that's hardly possible.

> I guess it's more to discourage the shared root password scenario than
> anything. 

Why should this be the distribution's task ? That's local policy, not
our business, we need to allow such configurations, not mandate them.

> Really, in the same token, should root ssh be disabled by default? 

It may be allowed to login only via publickey/gssapi auth and not
password auth I guess. But again this look more like admin policy than
something the distribution should enforce by default, IMO.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York