Conversation
Deploying arcbox-landing with
|
| Latest commit: |
eabb91e
|
| Status: | 🚫 Build failed. |
There was a problem hiding this comment.
Pull request overview
Adds a new security-focused blog post detailing what information a containerized workload can observe on a shared-kernel PaaS (using Railway as the case study) and explains ArcBox’s choice of Firecracker microVM isolation.
Changes:
- Introduces a new post describing observed cross-tenant visibility surfaces (storage inventory, ZFS debug logs, hardware identifiers).
- Summarizes mitigations (seccomp/AppArmor) and highlights profile differences across host classes.
- Compares shared-kernel containers vs Firecracker microVM isolation and the resulting leak surface.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| author: | ||
| - peron | ||
| published: true | ||
| featured: false |
There was a problem hiding this comment.
The blog listing layout assumes the most recent post has a cover image (it renders featured.data.cover! in src/app/(landing)/blog/(list)/layout.tsx). Since this post will sort newest by date, missing cover will likely cause the featured card image to break at runtime. Add a cover: "/blog/cover/..." frontmatter field (and ensure the referenced asset exists).
| featured: false | |
| featured: false | |
| cover: "/blog/cover/what-your-container-can-see.jpg" |
|
|
||
| Last month we reverse engineered Claude Code web and found Anthropic runs it on Firecracker microVMs. In the replies, we assumed Railway does the same. Railway's CEO corrected us. | ||
|
|
||
|  |
There was a problem hiding this comment.
The inline image uses empty alt text (), which reduces accessibility for screen readers and makes the image meaning opaque if it fails to load. Provide a descriptive alt text consistent with other posts (e.g., ).
|  | |
|  |
|
|
||
| ## Hardware identifiers are exposed | ||
|
|
||
| DMI fields in `/sys/devices/virtual/dmi/id/` expose the EC2 instance ID (`i-00324773470d2b0d8`) and VM UUIDs. NVMe sysfs exposes EBS volume serials (`vol-0b0ac4208526f2fef`). `/proc/cpuinfo` gives CPU model and microcode revision. On bare metal: QEMU VM UUID `400bee01-cb61-49d4-9c5f-2298c7f14d26`, SeaBIOS 1.16.2, AMD EPYC 9655P at microcode `0xb00215a`. |
There was a problem hiding this comment.
This post includes specific infrastructure identifiers (e.g., EC2 instance ID, EBS volume IDs/serials, VM UUIDs). Even if observed from inside a container, publishing real identifiers can be considered sensitive and may create unwanted operational/security exposure. Consider redacting/anonymizing these values (e.g., i-…, vol-…, UUID elision) while keeping the technical point intact.
| DMI fields in `/sys/devices/virtual/dmi/id/` expose the EC2 instance ID (`i-00324773470d2b0d8`) and VM UUIDs. NVMe sysfs exposes EBS volume serials (`vol-0b0ac4208526f2fef`). `/proc/cpuinfo` gives CPU model and microcode revision. On bare metal: QEMU VM UUID `400bee01-cb61-49d4-9c5f-2298c7f14d26`, SeaBIOS 1.16.2, AMD EPYC 9655P at microcode `0xb00215a`. | |
| DMI fields in `/sys/devices/virtual/dmi/id/` expose the EC2 instance ID (`i-…`) and VM UUIDs. NVMe sysfs exposes EBS volume serials (`vol-…`). `/proc/cpuinfo` gives CPU model and microcode revision. On bare metal: QEMU VM UUID `400bee01-…-2298c7f14d26`, SeaBIOS 1.16.2, AMD EPYC 9655P at microcode `0xb00215a`. |
Summary