[ec2-beta] document: EC2 Ubuntu sudo Guide

[Jim Cheetham]

On Mon, Mar 9, 2009 at 4:03 AM, Michael Greenly <mgreenly at gmail.com> wrote:
> I disagree.  It shouldn't do something different than every other AMI unless
> there' s some advantage.

It sounds like you have just argued that "all AMIs should be
configured the same way". There is "some advantage" -- it's just that
it doesn't seem to be an advantage _to you_. Nothing wrong with that;
just don't expect people who are comfortable with the regieme to be
interested in changing it without strong technical reasons.

Do you expect all distributions of Linux to be the same as each other
as well? Because I can't see anything EC2 specific in your concerns
here at the moment.

> Except that 'sudo su' works and that steps right past all the logging.

No, 'sudo su' (and 'sudo -i' 'sudo -s' 'sudo /bin/sh' etc) all log the
fact that user became root at a particular time. I suspect that you
are not often working in an environment with a whole team of admins;
there is a significant value to having this type of audit information.
It's not for everyone.

> I'm just hoping that the people who made the decision to deviate from the
> norm can point me to some literature that describes why it was a good idea?

I'm not a member of the Ubuntu Security Team. You can find them via
the wiki at https://wiki.ubuntu.com/SecurityTeam/GettingInvolved

It sounds like the 'sudo' questions you have should be directed at the
ubuntu-hardened section.

Documents describing the current security policy :-

https://help.ubuntu.com/community/RootSudo
and
http://ubuntuforums.org/showthread.php?t=765414

> If changes that effect security are being made without adequate planning
> that concerns me.

The issue of the root account being locked, and sudo being used to
elevate privs was an original design policy for Ubuntu, back in 2004.

> As a side note, in case this hasn't occurred to any else.  Elastic IPs make
> it very easy to limit in bound connections to specific IP addresses.  You
> create an transient server to act as an intermediate.  You only bring the
> transient server from a fresh AMI when you need to make connections.  This
> means that it usually isn't up and gives attackers very little time to
> target it.  Then you configure the applicaiton server to only accept
> connections from the IP address assigned to the transient server.

Even better, the public machine with the Elastic IP would be the only
machine capable of receiving connections from the Internet; all the
others would be talking on the private address space/second interface,
which only routes traffic within the EC2 space.

Of course, you still shouldn't trust the population of EC2 machines to
be any less dangerous than the Internet itself; it's just that there
are less of them, and consequently fewer compromised machines in
there.

-jim