[CHANGE PROPOSAL] The securetty file is empty by default

[Simo Sorce]

On Thu, 2014-04-03 at 07:32 -0700, quickbooks office wrote:
> This change will not affect logging into the console using the local
> account and then doing su to get root privileges.

What "local" account ?

> Is there a problem with logging into the local user account and then
> typing su and the root password?

Yes, in most installation I do not have any "local" user, I have only
users coming via LDAP, and if the problem I need to solve is that the
LDAP part of the equation is broken I have no user to log in if root is
disabled.

> You are as such prompted to make a local user account when doing an
> install from the Live CD.

Which is not the only mean of installing, nor the main mean for me (I
never used the LiveCD for installing).

You are clearly making assumptions that do not hold for the general
case.

Simo.

> "3.1.4.2.2. Disabling Root Logins
> 
> To further limit access to the root account, administrators can
> disable root logins at the console by editing the /etc/securetty file.
> This file lists all devices the root user is allowed to log into. If
> the file does not exist at all, the root user can log in through any
> communication device on the system, whether via the console or a raw
> network interface. This is dangerous, because a user can log in to his
> machine as root via Telnet, which transmits the password in plain text
> over the network. By default, Fedora's /etc/securetty file only allows
> the root user to log in at the console physically attached to the
> machine. To prevent root from logging in, remove the contents of this
> file by typing the following command:
> 
> echo > /etc/securetty
> 
> Warning
> 
> A blank /etc/securetty file does not prevent the root user from
> logging in remotely using the OpenSSH suite of tools because the
> console is not opened until after authentication. "
> 
> 
> The change will NOT affect: "Programs that do not log in as root, but
> perform administrative tasks through setuid or other mechanisms...The
> following programs are NOT PREVENTED from accessing the root account:
> su, sudo, ssh, scp, sftp"
> 
> On Thu, Apr 3, 2014 at 6:06 AM, Simo Sorce <simo at redhat.com> wrote:
> > On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote:
> >> On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote:
> >> > How does someone express strong disagreement to this change ?
> >>
> >> Posting here is a good start. You can also add a note in the FESCo ticket
> >> for approval once one is filed, and if you are incredibly passionate you can
> >> come to the FESCo meeting (although I'm hoping we can make those meetings
> >> more efficient, so that's not a good place for back and forth -- if possible
> >> we should work out the issues before the meeting).
> >
> > Ticket number ?
> >
> >> > This change makes it very hard to do necessary maintenance. I can
> >> > understand blocking SSH login as root with password by default, but I do
> >> > not understand what is the point of blocking console login as root.
> >>
> >> I assume that it's for a kiosk or public (or at least managed) lab
> >> situation. It makes sense for that, but I'm not convinced of a benefit
> >> otherwise, and I don't think that situation is the default....
> >
> > I am not even sure it makes sense in a kiosk, unless people want to use
> > "password" as their root password. But even if it made sense in that
> > situation it is far from being a useful *default*. This kind of severely
> > restricting measure is best left to hardening manuals.
> >
> > Simo.
> >
> > --
> > Simo Sorce * Red Hat, Inc * New York
> >
> > --
> > devel mailing list
> > devel at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> -- 
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


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