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:
>>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
>>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
>If we have to have a default user configured in the package, then
>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.
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
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.