5 ms·

Metadata servers should not exist. An application having network access should not grant it any sensitive privileges.

formerly_proven 5y ago
So I just read up on what this is and what they're for and can't help the feeling this is an "everything is a nail" design.
- CodesInChaos 5y ago
  The traditional unix "everything is a file" approach would be much better than those metadata services.
  - jcims 5y ago
    Totally agree. A block device with the contents of the metadata service in it would be nice! It becomes trivial to provide at least basic access control to the service.
    - rkeene2 5y ago
      This is done by some cloud software (e.g., OpenNebula). The downside is that modifying the metadata is now difficult since block devices being hot-plugged can cause issues if in use.
edf13 5y ago
It's far worse... the Metadata can provision a new public ssh key to the VM (at will!). I wasn't aware of this single point of failure
cesarb 5y ago
Last time I helped administer a deployment on one of these clouds, one of the first things we did on the startup script for the instances was to install an iptables rule so that only uid 0 (root) could talk to the metadata servers. The need for that kind of firewall rule on every instance shows that these metadata servers are a bad design. It would be much better if, instead of the network, these metadata servers were only visible as a PCIe or MMIO device. Of course, that would require a driver to be written, so at least initially, unmodified distributions would not be able to be used (but after a few years, every Linux and BSD distribution, and perhaps even Windows, would have that driver by default). That way, it would (on Linux) appear as files on /sys, readable only by root, without requiring any local firewall.
- amluto 5y ago
  There are ways for (virtual) firmware to expose data directly into sysfs, e.g. DMI and WMI. There are probably nicer ones, too. A virtio-9p instance exposing metadata would do the trick, too. Or trusted emulated network interface.
- rjzzleep 5y ago
  Is there a list of these mitigations somewhere?
- nijave 5y ago
  vsock might be a good solution
  - CodesInChaos 5y ago
    I don't think vsock supports any form of access control.
rkeene2 5y ago
OpenNebula solves this by attaching an ISO image with credentials and metadata to the CD-ROM virtual device, so only root can get the credentials to make calls and also the metadata is there.

So I just read up on what this is and what they're for and can't help the feeling this is an "everything is a nail" design.

CodesInChaos 5y ago
The traditional unix "everything is a file" approach would be much better than those metadata services.
- jcims 5y ago
  Totally agree. A block device with the contents of the metadata service in it would be nice! It becomes trivial to provide at least basic access control to the service.
  - rkeene2 5y ago
    This is done by some cloud software (e.g., OpenNebula). The downside is that modifying the metadata is now difficult since block devices being hot-plugged can cause issues if in use.

edf13 5y ago

It's far worse... the Metadata can provision a new public ssh key to the VM (at will!). I wasn't aware of this single point of failure

cesarb 5y ago

Last time I helped administer a deployment on one of these clouds, one of the first things we did on the startup script for the instances was to install an iptables rule so that only uid 0 (root) could talk to the metadata servers. The need for that kind of firewall rule on every instance shows that these metadata servers are a bad design. It would be much better if, instead of the network, these metadata servers were only visible as a PCIe or MMIO device. Of course, that would require a driver to be written, so at least initially, unmodified distributions would not be able to be used (but after a few years, every Linux and BSD distribution, and perhaps even Windows, would have that driver by default). That way, it would (on Linux) appear as files on /sys, readable only by root, without requiring any local firewall.

amluto 5y ago
There are ways for (virtual) firmware to expose data directly into sysfs, e.g. DMI and WMI. There are probably nicer ones, too. A virtio-9p instance exposing metadata would do the trick, too. Or trusted emulated network interface.
rjzzleep 5y ago
Is there a list of these mitigations somewhere?
nijave 5y ago
vsock might be a good solution
- CodesInChaos 5y ago
  I don't think vsock supports any form of access control.

rkeene2 5y ago

OpenNebula solves this by attaching an ISO image with credentials and metadata to the CD-ROM virtual device, so only root can get the credentials to make calls and also the metadata is there.