News for hackers. Stuff that matters.
Re:EC2's most dangerous feature by rcaught on Sunday October 09, 2016 @09:39AM (#12671139)
> almost as trivial for EC2 instances to expose XenStore as a filesystem to which standard UNIX permissions could be applied, providing IAM Role credentials with the full range of access control functionality which UNIX affords to files stored on disk.

Doesn't this become more complicated when you think about EC2 offering Windows instances? Even with straight UNIX file writing, what writes this? Where does it write this? Which user has read permissions?

Re:EC2's most dangerous feature by jamiesonbecker on Sunday October 09, 2016 @10:34AM (#12671351)
In UNIX, the same way that EBS volumes are mounted... think of the /proc or /sys virtual filesystems.

In Windows, I'm guessing that this would be exposed as a network drive.

Re:EC2's most dangerous feature by rcaught on Sunday October 09, 2016 @08:00PM (#12674243)
My point is that these type of solutions create a lot more overhead, inconsistency and variation compared to a HTTP request; granted, less security.
Re:EC2's most dangerous feature by eeeeeeeeeeeee on Monday October 10, 2016 @12:28PM (#12678082)
I'm sure that's why they went with HTTP -- it is universal and will work the same way everywhere.

I still think they should just disable it by default, so you have to "opt-in" to the potential security risk and plan accordingly.

Re:EC2's most dangerous feature by skywhopper on Sunday October 09, 2016 @10:04AM (#12671217)
Yeah, having the metadata available over an http interface is actually brilliant. Simple HTTP calls are easy to do from any network-capable OS or language.
Re:EC2's most dangerous feature by jamiesonbecker on Sunday October 09, 2016 @10:35AM (#12671356)
So is reading a file on the filesystem.. easier, actually in most languages, since HTTP requests usually require loading an extra library.
Re:EC2's most dangerous feature by ChoHag on Sunday October 09, 2016 @12:15PM (#12671813)
A library which uses the same (built-in) underlying IO mechanisms as the (built-in) filesystem.