On 5/19/19 8:48 AM, Christopher wrote: > On Fri, May 17, 2019 at 4:35 PM Kevin Fenzi <ke...@scrye.com> wrote: >> >> On 5/17/19 5:23 AM, Stephen Gallagher wrote: >> >> ...snip... >> >>> 3) Force Anaconda to require the creation of a non-root user that is a >>> member of the `wheel` group, so that this user can be used to SSH in >>> and administer the system. Essentially, remove the root user creation >>> spoke as an option from the interactive install. >> >> So, this is basically the old cloud-init makes a user that can sudo to >> root thing. Can anyone explain in small words how this is more secure? >> > > If you've ever examined your audit logs for failed authentications, > you'll notice the difference is substantial. The root user is under > non-stop attack over ssh, by countless bots and malicious users. Other > users are not so frequently targeted. The attack surface is > dramatically reduced when disabling access for the the root user over > ssh, and replacing that with a different user. This is not perfect > security, but it reduces the attack surface that can be automatically > targeted by automated attack tools.
I guess this is not the old cloud-init thing, since the proposed action here leaves the non-root user with a password. In cloud-init land, there's no passwords, the non-root user has a key. In that case I cannot see any difference between root having a key and the non-root user having a key and being able to sudo to root. One objection to this proposal last time this came up was that the device was going to join a ipa domain or the like, and a local non-root user was not desired. I suppose in that case they could delete the user after the initial setup. > >> I mean, in this case the attacker would need to guess the username in >> addition to the password (where in the cloud cause this is known), but >> otherwise why not just keep root password access ? >> > > The other user is not necessarily known, even in the cloud case. At > least on Amazon EC2, cloud-init can be used to parse user-data passed > in to add a user dynamically at launch time, rather than have the > default user well-known in the cloud image. Sure, and it can also not make one and leave root, but in practice I don't know too many people that do this. If you looked for 'fedora', 'centos' and 'rhel' and 'ubuntu' you would get most of them. As noted, the cloud-init case has no passwords, only keys. > >> I always found that cloud default anoying and useless and haven't yet >> seen a good argument to not do it. > > Cloud default users are, from my limited experience on AWS and looking > at my own audit logs, are nearly as often targeted by attackers as the > root user. So, I find these defaults annoying, too. The secure > position shouldn't be to admit defeat and leave password-based login > for the root user open on SSH... the secure position should be to > immediately create a new user during setup (either via kickstart, > anaconda, or cloud-init) that isn't a built-in default user (either > built-in to the OS, as "root" is, or built-in to the cloud image, as > "fedora" and "centos", etc. users are). If I am using ssh keys, I don't care about people trying to brute force passwords. Forcing the root account closed and having to use a 'user' account to login and sudo just seems like a pointless hoop. root account with key -> login as root with key user account with key / root locked -> login as user, sudo Thats another shell running, another sudo process, etc. Anyhow, thats not this case, so I should move along. At this point I think I am ok with the change, but I would really like to hear from some folks that didn't like it the last time it was proposed to see if we missed any cases. kevin
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
