Will System.Reflection be blocked?

While I understand Reflection can be a little too permissive sometimes, there’s a lot of good use cases for it.

For example, a lot of well known libraries such as Discord.NET and DSharpPlus use it to grab commands from classes through attributes:

[Command("mycommand")]
[Aliases("someothername")]
public async Task DoCommandAsync()
{
    Console.WriteLine("MyCommand was ran.");
}

You would be able to grab these with Reflection. Consider this long LINQ statement.

// Yes, I do understand .NET 5 has deprecated AppDomain, this is just for the example.
var commandMethods = AppDomain.CurrentDomain.GetAssemblies()
    .SelectMany(a => a.GetTypes())
    .Where(t => t.IsSubclassOf(typeof(CommandModule)))
    .SelectMany(t => t.GetMethods())
    .Where(m => m.GetCustomAttribute<CommandAttribute>() != null)
    .ToList();

I feel like this would allow for more flexibility for addon developers such as myself that wish to implement frameworks other developers could use.

Will you permit/lightly restrict it’s use or will it be outright blacklisted?

1 Like

I think that you will be able to use reflection for attributes and some other simpler stuff like getting types, etc…, because it isn’t really a security risk. Would be a real shame if we couldn’t use attributes.
Dynamically loading stuff and doing other stuff at runtime will definitely be blocked though (and it makes sense)

Yeah I could see that getting blocked, hopefully the safer stuff will stay.

1 Like

I don’t really see why reflection would be blocked. Garry has said we can do whatever we want serverside; and I don’t think the client will be able to load external assemblies from addon code.

I’m looking forward to using reflection for patching/modding other people’s addons at runtime.

1 Like

Yeah but it’d be nice to be able to use it clientside.

1 Like

Apologies, I didn’t make myself clear; I don’t see why reflection would be blocked clientside. I mean, I don’t see us having the abillity to load arbitrary dll files on the client. I’m talking about external dependencies as asssemblies that are not already running by the client.

1 Like

Yeah fair enough. I just want to use it to reflect on classes/methods/attributes of other addons, shouldn’t be too much to ask, hopefully :face_with_head_bandage:

1 Like
var method = typeof(File).GetMethod("WriteAllBytes", BindingFlags.Static | BindingFlags.Public);
method.Invoke(null, autostartFolder, myVirusExeBytes);
1 Like

Nice System.IO.File you have there

On the actual topic of sandboxing s&box. I don’t think Garry has tried yet.

Edit: why is quoting code broken?

3 Likes

Yeah, that would allow you to essentially bypass the method/property whitelist system made by garry, so i don’t think it’s feasible to fully unrestrict reflection.

1 Like

The code is pseudo code, I just wanted to show that you can bypass restrictions this way (assuming its static IL analysis and not checked at runtime). Reflection usage can not be statically analyzed.

Doesnt even need a direct reference to System.IO.File, you could just do Type.GetType(“mscorlib, System.IO.File”) instead.

Edit: they could create wrappers that only returns or invokes whitelisted stuff or edit the source code of reflection code directly. Would be slower but reflection is already slow anyway.

3 Likes

Yeah of course that’s true!

I’m not that experienced with the internals of C#, but something tells me that even if they did go through all the effort of restricting reflection, it won’t prevent people from simply bypassing what changes they make, they’ll have to change the execution permissions addon code has (e.g, don’t bother editing the libraries, remove their lower-level bindings entirely).

Since .NET Core & 5 don’t have Code Access Security (CAS) and AppDomains anymore, the .NET runtime doesn’t have such permissions or isolated environments anymore. All code runs with the same privileges. CAS and AppDomains werent great solutions either and had their own problems.

1 Like

Well that sounds like it’ll be a fun time for garry and the team to harden! I’m sure we’ll get some interesting exploits in testing :yum:

1 Like

Worst case they block reflection and make give us ways to get methods/types of loaded addons maybe.