Mxc: Microsoft Execution Containers version 1.0.0
blogs.windows.com
blogs.windows.com
Our current answer of just making the security model more and more complex isn’t working. It just means that, when things inevitably fail, we can say “well, they didn’t secure it correctly”. When even describing what is correct is hard, and setting it up is harder.
Honestly, this looks good, but we need a root and branch rethink of security if we want something that can protect us from rogue agents.
Excel, VSCode, Outlook, etc the permission model is a modal, "Do you trust this?" binary choice to enable full permissions to everything.
Not to say it's good or bad, just not the target market.
You do know about all those security training courses HR makes your take every year that you skip over?
Even the bubblewrap integration docs are basically a stream of consciousness vibe splat. I have approximately zero confidence in the results.
(reposted from the other copy of basically this post: https://news.ycombinator.com/item?id=50026061)
I think it's a good idea to create such an abstraction, but it's still far away from a 1.0 release.
I’m sure I could come up with an awkward abstraction, but bad abstractions are a bad way to build secure systems.
This is a first step: uncertain, unstable, with many improvements to build upon; but always a step, enabling pioneers out there to explore something new.
Thanks for sharing!
With that- I was running into essentially what is described here https://github.com/openai/codex/issues/47383
https://en.wikipedia.org/wiki/Most_Extreme_Elimination_Chall...
This seems like a nice-to-have, but I’d much rather see Azure 2.0. A ground up rebuild of a cloud that has a modern foundation with networking and security architected natively.
Naturally, this will be gated to corporate customers - the plebs do not get access to better security unless they pay for a top tier license.
I wonder if I will be able to integrate this with dev containers somehow, so my dev container could run in stricter isolation.
https://code.visualstudio.com/docs/editing/workspaces/worksp...
Maybe you use GitHub codespaces?
I don't believe this is what MXC accomplishes. Happy to be told otherwise!
...so make it its own security principal, distinct from the human user?
> Without a managed execution boundary, the agent may decide that changing the server configuration is the fastest way to complete the task and potentially break the production site.
It can decide that even with the execution boundary in place, you know. What matters if it can actually act that out.
All in all, a very sloppily written announcement. Almost as if it was written by—
That presumes the existence of a security context, which this product provides. Where do you configure the security principal otherwise?
root/non-root split is almost entirely used as a "don't let people accidentally shoot themselves in the foot" mechanism these days. Like you don't want your point-of-sale operator to accidentally disable the network or mess up the firewall rules effectively bricking the machine. Requiring an IT person to make the trip to fix it for them. But you would never "trust" the separate user profile on that POS machine as something keeping a purposefully malicious employee out of a secure system. The entire machine, regardless of the user profile, is the same security context. The uid/gid concept is an antique from the 80s that stopped working a long time ago. It's just an organizational primitive now for the most part.
I remember the fun days of the 90s and early 2000s when there were shared machines that a ton of people would ssh or rdp into with different user account and "share compute". It was fun, but absolutely no bueno for a long time now.
I ... what? Huge swaths of the computing landscape depend entirely that model. Schools (from primary to academic research), Windows Active Directory workplaces, thousands of cheap VPS providers ... the list is very long. All of those contexts absolutely use user accounts on the same running OS kernel as a security boundary. I've seen more than a few academic and government worksites where effectively radioactive data owned by one user was on the physical machine that other users routinely used--just not in an account they could access. Those places' infosec history wasn't perfect, but not because of the insider-threat-on-shared-machine risk.
In cloud/webtech, I think it's easy to overlook just how many massive organizations rely on stuff like shared AD workstations, cheap user-based shared hosting, or shared HPC a la "every member of the university gets an account on the SLURM cluster and we slice compute allocations by account--and separate accounts prevent the new intern from seeing protected IP".
Like, malicious employees can attack such systems, yes. But with adequate mitigations (network partitioning, internet access control, auditing/telemetry, good SEIM, user data encryption where appropriate, patching...all the usual good practices) this is a perfectly viable security model. Not perfect, but nothing's perfectly secure and every security paradigm has tradeoffs.
Those environments aren't dinosaurs or asking for a security disaster; they've made considered risk assessments and decided that the multi-user-machine security model works for them.
You're then brining an entire MS tech stack from the mid 2000s just to achieve something that has been solved by virtualization with a lot less caveats a long time ago.
> You're then brining an entire MS tech stack from the mid 2000s just to achieve something that has been solved by virtualization with a lot less caveats a long time ago.
Well, yes. Honestly, it'd be nice to have an OS where recursive virtualization is a built-in primitive instead of whatever the hell we've been doing for the last 40 years over and over.