Default cloud user name

[Steven Hardy]

On Sun, May 26, 2013 at 06:57:44PM -0700, Steven Dake wrote:
> On 05/25/2013 01:09 PM, Steven Hardy wrote:
> >On Fri, May 24, 2013 at 04:32:15PM +0200, Juerg Haefliger wrote:
> >>Hi all,
> >>
> >>Per Matt's request, I'm starting a new thread about the default user
> >>name for Fedora cloud images. Currently it's 'ec2-user' which I don't
> >>really like. OK, coming from the OpenStack-side of the cloud I might
> >>be a little biased :-) Nevertheless, I think we want to achieve an end
> >>goal of a single image that can be used in different cloud
> >>environments rather than having different images for the different
> >>environments. As such, the user name needs to be cloud/service
> >>provider independent. Following the lead of Ubuntu and Debian I
> >>propose to use 'fedora' as the default user name for F19 and going
> >>forward.
> >If we have to have a default user configured in the package, then "fedora",
> >or "fedora-user" gets my +1.
> >
> >I also agree that just using root would be easier & less confusing, since
> >the paswordless sudo amounts to that anyway.
> Steve,
> 
> Applications run as the user (fedora-user) and would need a more
> complicated attack vector to escalate privileges via sudo then a
> root run daemon running inside the instance would (No remote
> execution of sudo plus other commands would be required).  For
> example, a network daemon running only as root could be attacked by
> reading files via the network via a non-remote-execution attack
> (think web app reading and displaying mysql passwords from the
> filesystem).  This mysql leak could then be used as a different
> attack, which would not have been possible if the app was running
> without non-privileged capabilities.

Sorry, but I really don't understand this argument at all - any sanely
packaged software will create a suitably unprivileged user to run their
application/daemon, and running them as a user which has passwordless sudo
rights seems like a terrible idea.

If people really are using the default user in the manner you describe,
then I think it is a good argument for not having a default
user at all (in the package), e.g make it part of the ec2 AMI for
historical reasons, but require other users of cloud-init to make an
explicit decision about what users are created and what privileges they
have via cloud-config.

Allowing SSH to the not-root-but-actually-is-root account negates nearly
all of the advantages of disabling root SSH logins, and in particular you
lose any audit trail because it's a generic account.

IMO in any environment where you actually care about security, you'd want
to remove the package-default user and instead provide admin access via
real user accounts (e.g configure centralized authentication or use some
other method which provides identification of the admin accessing the
system)

> Further complicating things, many applications will not run when
> root capabilities are present in the process (they self-check and
> complain don't run as root).

So they create a user in the RPM at install time.

Cheers,

Steve