One look at this init script, and I'm pretty sure it should just be masked for removal. It's grabbing random data over plain HTTP and stuffing it into /root/.ssh/authorized_keys? Okay...
Sounds like security business to me. However, feel free to mask it straight away.
Please unmask it. If you want to mask it on account of doing what SEEMS to be security-fail, then you also need to remove other tools that do the same thing: cloud-init, amiconfig, flamingo [1], etc. The trick, and why this SHOULD stay, is to look at the address: 169.254.169.254 In an EC2 environment, or anything else that implements that same metadata system (there are implementations for OpenStack, Ganeti [2] & others), 169.254.169.254 is a special address within the 169.254.0.0/16 IPv4 link-local block, authenticates the request by out-of-band-means (eg traffic from the correct hypervisor switchport), and provides a response. If you install this package in a non-cloud environment, your attack scope is still limited the local network. [1] https://github.com/tmrts/flamingo [2] http://docs.ganeti.org/ganeti/2.15/html/design-os.html#metadata-service
Yes, please stop removal if the only reason were security concerns. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html to learn more about this service.
It's not just the HTTP data, but the fact that damn near everything can go wrong: depend() { before hostname need net.eth0 } Hard-coding the interface name... local hostname=$(wget -t 2 -T 5 -q -O - http://169.254.169.254/latest/meta-data/local-hostname) echo "hostname=${hostname}" >> /etc/conf.d/hostname What if that outputs an error? wget ... >> >> /root/.ssh/authorized_keys Same here. if [ -f /root/.ssh/authorized_keys ]; then chown root:root /root/.ssh/authorized_keys chmod 0600 /root/.ssh/authorized_keys fi Messing with the ownership and read/write bits on one of the most sensitive files on the system? The security concerns aren't why I filed the bug, but anyone on your physical segment can grab root, right? That init script is likely to screw up your machine if you use it long enough. It needs to be rewritten, but of course there's no maintainer. I'll drop the mask if you insist, but I think this is asking for trouble.
And to beat a dead horse: mkdir -p /root/.ssh Now root's private .ssh directory is world-readable. For an example of what can go wrong, if I run this on one of my machines with an eth0, then $(wget ...) returns the empty string, and echo "hostname=${hostname}" >> /etc/conf.d/hostname wipes out the hostname and breaks postfix.
I've submitted a proxy-maintainer request for app-admin/amazon-ec2-init via bug #604998.
https://github.com/bparsons/ec2-init perhaps this might make a good alternative?
(In reply to Reuben Martin from comment #7) > https://github.com/bparsons/ec2-init > > perhaps this might make a good alternative? It's a lot better but not all the way there. I listed the issues that need to be fixed over in bug 604998. Not all of them are critical, though. Here's what ec2-init would fix: 1. It doesn't always overwrite your hostname configuration. It still tries to with open('/etc/hostname', 'w'), but that will fail if the file doesn't exist. It still shouldn't do that, though. 2. It checks for HTTP errors to avoid trashing the system. 3. It's better about appending duplicate keys and messing up the permissions on /root/.ssh, but it still isn't perfect. But here's what it doesn't: 1. We still need a guard like I_KNOW_WHAT_I_AM_DOING in a conf.d file to prevent people from running this accidentally. The user should acknowledge the fact that anyone connected to his ethernet port is about to gain root. 2. There's no stop() to undo the things that the script does. I would say the only critical thing is the guard variable to prevent people from running the init script accidentally. It's not so bad if the missing stop() permanently changes your system after you've claimed that I_KNOW_WHAT_I_AM_DOING.
Sorry for the radio silence. I've been chipping away at a version of the original script to satisfy @mjo's requests. Hopefully I'll be done in the next few days and submit a pull request. A few points I've realized the last few weeks: 1.) I realized I don't need this script at all because I don't care about dynamic hostnames & SSH keys. But that's because I run a single static server with a persistent drive, as opposed to the standard ephemeral drives that most EC2 instances use. So some of you might also not require this script at all, if you've just installed it because https://www.artembutusov.com/gentoo-on-aws/ mentioned it, but aren't spinning up instances of an AMI that doesn't have a stable user system. 2.) It seems the "plus" of this script is that it's simple and minimal. Amazon Linux uses cloud-init instead of a small script like this, but it gives them features like scripts to run at start-up and control over initialization of the system. It would seem to me that people that need more advanced features should look at cloud-init or a similar product. 3.) I_KNOW_WHAT_AM_DOING=1 usually allow people to unlock dangerous sub-features; but this whole script requires extreme trust of 169.254.169.254. It feels to me that this script should be permanently masked with a message stating that it trusts the local network excessively and is only intended to be used on Amazon's EC2 service. (But not masked for removal.) Unmasking would be acknowledgement and acceptance of that warning. If anyone disagrees with the above, let me know (and why, so I can understand).
(In reply to Philippe Chaintreuil from comment #9) > It feels to me that this script should be permanently > masked with a message stating that it trusts the local network excessively > and is only intended to be used on Amazon's EC2 service. (But not masked > for removal.) Unmasking would be acknowledgement and acceptance of that > warning. I've updated the mask to say that it's masked for QA/security issues. I'm not going to remove it so long as people need it, and having it masked should be enough to prevent accidental use. Although if somebody still wants to fix it, that's cool too =)
