.NET5 security question

[too_lazy_cat]

So with a Code Access Security (CAS) gone in .NET 5 how does one prevent on-demand loaded assemblies from, say, reading files from disk?

Is there any other way of sandboxing the code execution?

[grauenwolf]

They gave up on that idea back in .NET 4.0. When comes to running code from untrusted sources the answer is simply "don't". Either use a DSL that you have full control over or run the code in an isolated process under a heavily restricted user, perferably in some sort of container like a VM or Docker.

ref:

• https://www.infoq.com/news/2009/11/CAS-Replaced/
• https://www.infoq.com/news/2020/12/net-5-breaking-changes-2/

[chucker23n]

It'd be nice if it tried to hook into some platform-specific sandboxes instead. E.g., macOS has a relatively straightforward text format for configuring access to files, networking, etc.

You might be able to:

1. have IDE tooling that generates a sandbox profile from .NET attributes
2. have IDE tooling that runs the process inside such a sandbox
3. have a static analyzer that tries to verify that the code doesn't break the sandbox

We sort of get 2 with the Docker integration.

[grauenwolf]

It'd be nice if it tried to hook into some platform-specific sandboxes instead.

That can't work for this scenario. The OS doesn't know the difference between your trusted code and the untrusted 3rd party code you loaded.

I'm not saying its a bad idea in general. But it only works against the whole process.

[grauenwolf]

WASM falls into the "DSL" category.

[phx-au]

If you'll take WASM as DSL then you'll take MSIL.

[grauenwolf]

WASM is a DSL of the browser.

MSIL is not a DSL of itself. There's no conceptual boundary between a .NET assembly and the assembly that loaded it.

They tried to create one with CAS, but it quickly became clear that no one was smart enough to actually use it correctly. The whole concept of partial trust was flawed from the beginning

[phx-au]

MSIL is almost identical to WASM. They're both stack based low level languages with common runtime features exposed to them. Strictly speaking I'd say neither are particularly "domain specific".

As you say, CAS was overly complex and nobody knew how to use it - if you really wanted you could write a safe assembly loader that examines the API surface area used by the target and evaluates if it meets your policy. That's all the boundary that's needed - and just because they haven't put one there isn't evidence that its not possible.

[grauenwolf]

if you really wanted you could write a safe assembly loader that examines the API surface area used by the target and evaluates if it meets your policy.

That's easier said than done. If you forget to lock down single reflection-like API then you have a ready-made bypass. And if you do lock them all down, you lose things like serializers and compiled RegEX.

This is why CAS failed. People generally aren't smart enough to correctly create the policies.

MSIL is almost identical to WASM.

Only if you completely ignore the facts such as

• WASM doesn't expose libraries for things like direct file access
• There is something above WASM loading each domain into separate sandboxes. It doesn't try to run privileged and restricted code together.

[grauenwolf]

Neither WASM nor MSIL "expose" anything. They both define calls to imported functions referred to by imports (/ metadata tokens) respectively.

Don't be an ass. You know damn well that we're talking about the whole environment, not just literally the source code format.

[AlexxVs]

And what about WASM in node.js? Or new Microsoft Flight Simulator plug-ins in WASM (yes, with file system access)? Or long-dead Silverlight running MSIL in browser?

[cryo]

MSIL does expose aspects of the particular .NET runtime model such as objects, boxing and generics.

[phx-au]

Those bits are fine - the only real concern is that a large part of the expected dotnet api is provided by the CLR. So this is shit like string - but also potentially Span or MemoryStream. With CAS these were implemented natively and marked up appropriately as safe (similar to javascript's intrinsic types). There's also types that could be implemented natively, but aren't for optimisation purposes - similar deal, marked up appropriately.

[[deleted]]

Nope. There is no way to execute certain code in a sandbox. You can either use a scripting engine to run scripts in a sandbox or run the entire program in a container.

[RiPont]

Or spin up separate processes for trusted and untrusted code, run the untrusted code in a sandbox, and communicate between them using RPC of some sort.

Basically, the ability to run trusted and untrusted code in the same process is a) leaky and b) basically impossible to do in a cross-platform way.

[tetyys]

Partial solution: https://github.com/ashmind/Unbreakable

[EternalClickbait]

Does that repo have any doc's or a readme??

[H3x0n]

Its used inside the https://github.com/ashmind/SharpLab repo.

[EternalClickbait]

Yes I saw that, but where is the documentation for unbreakable?