On 5/19/19 8:48 AM, Christopher wrote:
On Fri, May 17, 2019 at 4:35 PM Kevin Fenzi <kevin(a)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