[ec2-beta] document: EC2 Ubuntu sudo Guide

[Michael Greenly]

On Sun, Mar 8, 2009 at 2:44 PM, Jim Cheetham <jim at inode.co.nz> wrote:

> 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.


Yes, I'm arguing that from a security standpoint it's better to stay with
well tested and tried processes unless there's a clearly measurable argument
in favor of the change.  To be fair I don't think that this approach weakens
security at all it just makes using the AMIs less convenient.

>
>
> 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.


That's exactly my point.  It only logs that you elevated your permissions.
It doesn't log what you do.  Just watching auth logs give you that info
without having to resort to sudo.


>
>
> > 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.


I'm asking the question here because some one involved with the Ubuntu EC2
AMI has made the decision to deviate from standard AMI practices.  I'd like
to see some justification to support that decision.


>
> 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.


The it's the same as Ubuntu Desktop/Server editions doesn't really justify
it for me.  They're different creatures used differently.  I happen to think
it makes perfect sense on a desktop that's typically self administered.  I
don't think it makes sense in an AMI.  If you read through your links and
look at the advantages only one of them could be said to apply in an AMI

   -

   Allows easy transfer for admin rights, in a short term or long term
   period, by adding and removing users from groups, while not compromising the
   *root* account.

So there is at least one advantage.  I'm not convinced it's advantage enough
to offset the disadvantages but it's something.


>
>
> > 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.


I don't really follow what you're saying here.  There's only one interface
on an EC2 instance.  What I was saying is that I always configure my
machines to only accept connections from known addresses.  That's not always
easy for everyone if they're working from  a dynamic assigned ip.  Amazon
offers a nice solution with elastic IP addresses.  Configure your ami so
that it only accepts connections from an address you've allocated with
elastic ip.  Then when you need to connect to your instance bring up a
temporary instance assign your allocated ip address to it and use it as a
gateway to your actual instance.  This provides actual security gains in
that the transient machine is rarely up to attack.  The actual machine will
never talk to anyone but it.

This bit is not really relevant to this conversation.  It was just a thought
I wanted to share.


>
> 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
>


I just wanted the AMI to be as easy for EC2 users as possible, by conforming
to standard practices found in that environment.  I think it's a bit of
diservice to Ubuntu users who are new to EC2 to not have amazon's tutorials
and commonly availabe guides work right out of the bag.

I have no interest in beating this horse anymore.

It hardly makes any difference to me which way it is.  It only takes a few
seconds to work around, or work with.  I still haven't decided.



-- 
Michael Greenly
http://blog.michaelgreenly.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/mailman/private/ec2/attachments/20090308/a48375e0/attachment-0002.htm