| Title | Domain | Score | Author | Age | Comments |
|---|---|---|---|---|---|
| Mxc: Microsoft Execution Containers version 1.0.0 | blogs.windows.com | 95 | smokel | 1 day ago | 17 |
| Title | Domain | Score | Author | Age | Comments |
|---|---|---|---|---|---|
| Mxc: Microsoft Execution Containers version 1.0.0 | blogs.windows.com | 95 | smokel | 1 day ago | 17 |
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.
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.
What are these people running from? They're not! They're running to the world's toughest competition in town!
Most Extreme Elimination Challenge (MXC)
https://en.wikipedia.org/wiki/Most_Extreme_Elimination_Chall...
> 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—
> ...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?
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.
The same-machine-multi-user security paradigm has been dead for a long time. Even on linux, you pretty much assume root or non-root and leave it at that. You then use other layers (namespacing, kvm, etc) to enforce actual security isolation and controls.
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.
Can you restrict accessible IP ranges by user?
It is possible with IIS, although it may require writing an actual plugin (which I did once, to do per-user routing; wasn't pleasant in the slightest). I don't know if it can be done out of the box.
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.
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.
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.
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.
VS Code workspaces doesn't seem to offer any protection:
https://code.visualstudio.com/docs/editing/workspaces/worksp...
Maybe you use GitHub codespaces?
No, I did mean VS Code workspaces. Now I'm going to go down this rabbit hole to better understand the boundary limits :)
Its a good idea and enterprise customers will love it.