On Thu, 2015-01-08 at 11:10 -0500, Adam Jackson wrote:
> On Thu, 2015-01-08 at 08:43 -0500, Stephen Gallagher wrote:
>
> > In the Server case, nearly every deployment is headless. Disabling root
> > login to ssh by default would mean that many people would have no way to
> > get into the system at all. (Yes, we could force the creation of a
> > non-root user at install time, but this user would by necessity be an
> > administrator capable of becoming root via sudo, so the distinction
> > is... fuzzy).
>
> It might be fuzzy but I don't think it's meaningless. Consider ssh's
> X11 forwarding. Prior to CVE-2013-19{81,97} libX11 had bugs where it
> would trust the server's replies to be correctly formatted, which meant
> the _server_ could exploit the _client_. Since in X the server is the
> display, this means if I can commandeer the user session then I can
> exploit the machine being ssh'd _to_.
>
> Cisco routers don't log you in directly to enable mode, even if there's
> no password. OSX runs your session as a user even though it gives you
> sudo by default. What's so different about Fedora Server that we should
> ignore common best practice?
>
The difference is that it's presently uncommon for users to install a
non-root *local* user account on the system. Most people will use 'root'
to get the system bootstrapped into being able to talk to a central
identity system (some flavor of Active Directory, FreeIPA or LDAP) and
then manage sudo rules from there.
Requiring us to ship with a new local user would mean a problematic
UID/GID overlap in a LOT of environments. (Since the vast majority of
companies just dump their previous /etc/passwd files into LDAP without
changing IDs, the UID 500 or 1000 is probably already in use and is now
essentially a backdoor root account).
So I stick with my original statement: if we enroll in a domain during
installation (using realmd), we can disable remote root logins and trust
that the authn/z provided by that domain handles privilege escalation
appropriately. If we are NOT in a domain right from the start, it's
potentially unsafe to introduce another user and that should be left to
the admin to resolve interactively.
(And for those of you who might suggest just using a sub-500 ID for this
special user, that has its own set of issues around the history of the
PAM stack and would be highly problematic).
> > The only other approach I could see for the headless
> > servers would be mandating the enrollment in an identity domain at
> > installation time (such as to FreeIPA or Active Directory).
>
> And in this scenario we should absolutely disable PermitRootLogin.
I don't think we disagree here. The only problem of course is one of
bootstrapping: how do you set up a FreeIPA domain controller on the
first machine...
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
