> - The 'method' used to restrict remote root access is negotiable. Ie. disable
> it completely by setting PermitRootLogin=no OR disable remote root login
> via password by setting PermitRootLogin=without-password.
(The general theme of this mail: Being flexible is fine, and establishing this
through this discussion is great; however, ultimately the Change proposal needs
to document the _specific outcome_ of that discussion.²)
> - Major concern so far is how this feature could break existing workflows.
> That is genuine and can be addressed adequately.
“Can be” or “will be”? How? It is vaguely worrying that the Change proposal
explicitly lists only the most trivial task to do (change a sshd.conf option)
and is only fairly generic about how other parts of the OS and users need to
and/or will adapt.
> PermitRootLogin=no
> * If we disable remote 'root' access, non-root user access becomes
> imperative.
> - Anaconda & cloud_init tools already facilitate creation of non-root user
> accounts.
> - Creation of one non-root account could be made mandatory.
> - Omission of non-root account creation could show discretionary warning.
> - Omission of such user account creation could conditionally enable remote
> root access.
“Could conditionally“… With my FESCo hat on, during the Change Checkpoints
FESCo will need to know whether the Change is sufficiently complete or whether
to fall back to the contingency plan. Having a “Could conditionally” nailed
down to yes or no would prevent general unhappiness if the respective package
maintainers thought that they have done the right thing and FESCo during review
suddenly decided that the right thing is the opposite.
Separately from the general theme above,
> - Second tune is that the feature does not add any security. That is like
> saying having a security guard at the entrance adds no value, because
> atrocities still continue to happen around us.
The requirement to know a user name, which is in most cases just an automatable
task¹ nobody is trying to prevent or make harder, is not really the same as a
requirement to bypass a security mechanism (subdue a guard or guess a
password). It’s been about 10 years already since I have witnessed an
automated password guessing bot carrying a list of user names and real names
from previously infected systems as a “crib sheet” for guessing on new systems;
this is not a hypothetical thing that bot authors are too dumb or lazy to do.
So this proposal only helps if we hope that a bot won’t try the right user
name; calling this security by obscurity is not too wide off the mark.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
