Mxc: Microsoft Execution Containers version 1.0.0 (blogs.windows.com)

136 points by smokel 2 days ago

moomin 5 hours ago

I’ve had a good think about this, and while it’s good to see them finally answering bubblewrap, the truth is that we as an industry have been ridiculously at permissioning for some time and this does not solve this. It’s all very well saying we have read only resource access, but then you connect up to JIRA and all of a sudden you’ve got a different identity system, different resource model and and more complexity than you can shake a stick at.

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.

3eb7988a1663 4 hours ago

Microsoft security is a bimodal. They might have exquisite delineation for network resources in Sharepoint or Azure but consumer applications are a joke.

Excel, VSCode, Outlook, etc the permission model is a modal, "Do you trust this?" binary choice to enable full permissions to everything.

Melatonic an hour ago

Seriously. Mobile devices have done a better job with this (in some ways) but it really should be a standardised thing of least permissions by default. And way. Way less confusing.

amluto 2 hours ago

Sadly, skimming the docs about how the different backends work makes me think that almost this entire project was done by a recent-gen LLM that interpreted its instructions as “make these things work at all costs” instead of “make a considered design that cleanly and securely fits its use case”.

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)

nilleb 2 hours ago

The biggest news - and the most welcome one - is that W11 25H2 August cumulative update now allows anyone to set up App containers without administrative privileges. Then they built mxc on top of that.

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!

agentdev001 an hour ago

Thats huge for enterprise, chatgpt desktop windows sandbox setup for users is a slog at the moment. Second big thing, Intune and identity via agent365 is on the way!

DeepYogurt 6 hours ago

What are these people running from? They're not! They're running to the world's toughest competition in town!

edoceo 5 hours ago

Joker_vD 6 hours ago

> An agent cannot be its own security authority. It must run within a boundary defined by the developer or organization and enforced independently of the agent itself.

...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—

esafak 5 hours ago

> ...so make it its own security principal, distinct from the human user?

That presumes the existence of a security context, which this product provides. Where do you configure the security principal otherwise?

freeone3000 5 hours ago

Windows already has a multi-user security context, with file- and API-level permissioning. We often call it “Users” or “RBAC”. I’ve read it and I’m still not sure what I can do now that I couldn’t a week ago.

eddythompson80 3 hours ago

MrBuddyCasino 3 hours ago

truetraveller an hour ago

I want a super-simple way to restrict an app's read/write to a specific dir. This is an incredibly useful solution that should have existed 20+ years ago. Why is this not a thing? This will basically solve most security issues immediately, in a super user-friendly way.

I don't believe this is what MXC accomplishes. Happy to be told otherwise!

jcoc611 an hour ago

You can launch arbitrary executables with MXC but different backends provide different security guarantees. Some backends like LPAC on Windows cause many exes to straight up fail during startup (powershell for instance)

3eb7988a1663 5 hours ago

Can I use this as a generic app permissions boundary or do I have to somehow fake it as an "agent"? We are well past the point where I need to be able to lock down that my music player has no ability to read my SSH keys or whatever.

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.

tomrod 4 hours ago

FANTASTIC question here. I've been locking down agents by running them as untrusted users (mostly linux here) as even docker boundaries aren't really great. Firecracker is a step in the right direction (older tech, sure, but useful). I really want a local hashicorp-like vault that I can give agents specific access permissions and it can take forever to review and manage those access boundaries.

doctorpangloss 3 hours ago

I guess buy a Mac then.

tuwtuwtuwtuw 4 hours ago

There are many things that would be good to lock down. NPM install comes to mind.

I wonder if I will be able to integrate this with dev containers somehow, so my dev container could run in stricter isolation.

tomrod 4 hours ago

I've seen folks using the VS Code workspaces concept for this. It's a bit limited but a good step in the direction I prefer.

tuwtuwtuwtuw 3 hours ago

chris_money202 6 hours ago

Its a good idea and enterprise customers will love it.