FileIOPermission also takes away UIPermission?
-
I was trying to limit some permissions on what certain methods can and cannot access. I wanted to disallow certain methods from accessing files. I found the
FileIOPermissionAttribute, this seemed exactly what I wanted. But alas, if I use this attribute I cannot call showdialog on a form object.[FileIOPermission(SecurityAction.PermitOnly)] private void button1_Click(object sender, System.EventArgs e) { Form2 fm = new Form2(); fm.ShowDialog(); }
The exception text: An unhandled exception of type 'System.Security.SecurityException' occurred in mscorlib.dll Additional information: Request for the permission of type System.Security.Permissions.UIPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed. Can anyone explain why a UIPermission exception is thrown? -Nathan --------------------------- Hmmm... what's a signature? -
I was trying to limit some permissions on what certain methods can and cannot access. I wanted to disallow certain methods from accessing files. I found the
FileIOPermissionAttribute, this seemed exactly what I wanted. But alas, if I use this attribute I cannot call showdialog on a form object.[FileIOPermission(SecurityAction.PermitOnly)] private void button1_Click(object sender, System.EventArgs e) { Form2 fm = new Form2(); fm.ShowDialog(); }
The exception text: An unhandled exception of type 'System.Security.SecurityException' occurred in mscorlib.dll Additional information: Request for the permission of type System.Security.Permissions.UIPermission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed. Can anyone explain why a UIPermission exception is thrown? -Nathan --------------------------- Hmmm... what's a signature?Because you're granting permissions ONLY for the FileIOPermission, not the
UIPermissionwhichForm.ShowDialogrequires. If you're new to .NET code access security, "UB" has an excellent article here on CodeProject, Understanding .NET Code Access Security[^]. You should also see the reference, Code Access Security[^], in the .NET Framework SDK.Microsoft MVP, Visual C# My Articles
-
Because you're granting permissions ONLY for the FileIOPermission, not the
UIPermissionwhichForm.ShowDialogrequires. If you're new to .NET code access security, "UB" has an excellent article here on CodeProject, Understanding .NET Code Access Security[^]. You should also see the reference, Code Access Security[^], in the .NET Framework SDK.Microsoft MVP, Visual C# My Articles
Is there and easy way to deny access to all files, but still allow UI to be presented to the user? Basically I am helping to develop a plugin architecture and we need to disable file access and possibly even socket access. So I was looking for something along the lines of:
// psuedo code filePerm.DenyAllAccess(); sockPerm.DenyAllAccess(); myPlugin.DoSomethingClever(); sockPerm.RevertDeny(); filePerm.RevertDeny(); `Thanks, Nathan --------------------------- Hmmm... what's a signature?` -
Is there and easy way to deny access to all files, but still allow UI to be presented to the user? Basically I am helping to develop a plugin architecture and we need to disable file access and possibly even socket access. So I was looking for something along the lines of:
// psuedo code filePerm.DenyAllAccess(); sockPerm.DenyAllAccess(); myPlugin.DoSomethingClever(); sockPerm.RevertDeny(); filePerm.RevertDeny(); `Thanks, Nathan --------------------------- Hmmm... what's a signature?`Typically, it's not your code's responsibility. That's what permissions sets that code groups use are for. I don't see why you're trying to do this like you are. If a plugin calls your method, your method was written by "you" (possibly an org.) so you ultimately control what goes on in there. If you don't use files or sockets, how is a plugin supposed to change that? Now, if you wanted to make sure that your application had certain permissions but plugins were more restricted, you should consider using a code group based on the strong name of your assembl(y|ies). With real-world applications, you should always sign your assemblies for added benefit, like the ability to be installed into the GAC, to be used by other strong-name assemblies, etc. Use the
AssemblyKeyNameAttributeor theAssemblyKeyFileAttributewith a file generated by "sn.exe -k KeyFile.snk", which generates a key pair. Use this for all of your assemblies (putting it in a container with "sn.exe -i MyContainerName KeyFile.snk" and using theAssemblyKeyNameAttributeis often easier with large projects). If you call one of your plugin methods as you do above, you have a number of things to consider. First, do you even trust the plugin? Perhaps checking the public key token and making sure it's the same as yours or another trusted source would be a good idea. If you want anyone to be able to extend your application, then you're on the right track. Create an instance of the permission(s) and callDenyon the instance. This also means that if callers higher in the stack are trying to access a resource, they won't be able to but aSecurityExceptionwill be thrown by callees lower in the stack when aDemandfor that permission occurs.Microsoft MVP, Visual C# My Articles
-
Typically, it's not your code's responsibility. That's what permissions sets that code groups use are for. I don't see why you're trying to do this like you are. If a plugin calls your method, your method was written by "you" (possibly an org.) so you ultimately control what goes on in there. If you don't use files or sockets, how is a plugin supposed to change that? Now, if you wanted to make sure that your application had certain permissions but plugins were more restricted, you should consider using a code group based on the strong name of your assembl(y|ies). With real-world applications, you should always sign your assemblies for added benefit, like the ability to be installed into the GAC, to be used by other strong-name assemblies, etc. Use the
AssemblyKeyNameAttributeor theAssemblyKeyFileAttributewith a file generated by "sn.exe -k KeyFile.snk", which generates a key pair. Use this for all of your assemblies (putting it in a container with "sn.exe -i MyContainerName KeyFile.snk" and using theAssemblyKeyNameAttributeis often easier with large projects). If you call one of your plugin methods as you do above, you have a number of things to consider. First, do you even trust the plugin? Perhaps checking the public key token and making sure it's the same as yours or another trusted source would be a good idea. If you want anyone to be able to extend your application, then you're on the right track. Create an instance of the permission(s) and callDenyon the instance. This also means that if callers higher in the stack are trying to access a resource, they won't be able to but aSecurityExceptionwill be thrown by callees lower in the stack when aDemandfor that permission occurs.Microsoft MVP, Visual C# My Articles
Heath Stewart wrote: If you want anyone to be able to extend your application, then you're on the right track. Create an instance of the permission(s) and call Deny on the instance. I would like others to develop plugins so that is why I wanted to deny things around the method calls into that plugin. I don't want plugins to be able to do anything evil and such to the user's computer or via the user's computer. The plugin should get all information from the program and that is it. I have found this to work around the method declaration of the abstract plugin methods.
abstract class plugin { // override this to add functionality protected abstract void OnDoSomething(); [FileIOPermission(SecurityAccess.Deny,Unrestricted=true)] public void DoSomething() { OnDoSomething(); } }This will stop file accessing. But I found that the plugin derived from this can just do anFileIOPermission.Assertto get around this. Maybe I am thinking too much and there is no truly safe way to do these plugins. Maybe at some point I have to trust my users... Thanks again, Nathan --------------------------- Hmmm... what's a signature? -
Heath Stewart wrote: If you want anyone to be able to extend your application, then you're on the right track. Create an instance of the permission(s) and call Deny on the instance. I would like others to develop plugins so that is why I wanted to deny things around the method calls into that plugin. I don't want plugins to be able to do anything evil and such to the user's computer or via the user's computer. The plugin should get all information from the program and that is it. I have found this to work around the method declaration of the abstract plugin methods.
abstract class plugin { // override this to add functionality protected abstract void OnDoSomething(); [FileIOPermission(SecurityAccess.Deny,Unrestricted=true)] public void DoSomething() { OnDoSomething(); } }This will stop file accessing. But I found that the plugin derived from this can just do anFileIOPermission.Assertto get around this. Maybe I am thinking too much and there is no truly safe way to do these plugins. Maybe at some point I have to trust my users... Thanks again, Nathan --------------------------- Hmmm... what's a signature?The assert only works if the code that is asserting that permission was granted that permission (not taking callers higher in the stack into account). Again, this comes down to effective management of permission sets and code groups. That's the only true way to limit it.
Microsoft MVP, Visual C# My Articles
-
The assert only works if the code that is asserting that permission was granted that permission (not taking callers higher in the stack into account). Again, this comes down to effective management of permission sets and code groups. That's the only true way to limit it.
Microsoft MVP, Visual C# My Articles
Thanks for all your help. I will just have to deal with them having the ability to Assert to get around it. I think it will stop most people from doing anything stupid... but it won't stop true hackers. Thanks again, Nathan --------------------------- Hmmm... what's a signature?