|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
[assembly: SecurityPermission] questionFxCop advise me to assign some security to my library, with this warning:
http://www.gotdotnet.com/team/fxcop/docs/rules.aspx?version=1.35&url=/Usage/AssembliesShouldDeclareMinimumSecurity.html I should confess that I have little knowledge about this, never done it before. And I face the following conundrum: On one hand my component won't use any system resource (no disk access, no socket access, etc...) On the other hand one of my DLL is a ManagedC++ wrapper around Uniscribe. I cant escape either of ManagedC++ or C# Interop, which requires maximum permission I believe. However what my library does and the function it exposes are all harmless (No pointer exposed, only bound checked .NET array) How to manage that? Check out the PermCalc tool
[http://msdn2.microsoft.com/en-us/library/ms165077.aspx] that ships with the ..NET framework SDK. This will give you a good idea of which permissions your assembly needs, but if you're interoping in C#, you typically will need the Unmanaged Code security permission (which is indeed the most permissive permission). Regards, Pieter Philippaerts Show quote "Lloyd Dupont" <net.galador@ld> wrote in message news:%23gIvzuekGHA.1260@TK2MSFTNGP05.phx.gbl... > FxCop advise me to assign some security to my library, with this warning: > http://www.gotdotnet.com/team/fxcop/docs/rules.aspx?version=1.35&url=/Usage/AssembliesShouldDeclareMinimumSecurity.html > > I should confess that I have little knowledge about this, never done it > before. > > And I face the following conundrum: > > On one hand my component won't use any system resource (no disk access, no > socket access, etc...) > > On the other hand one of my DLL is a ManagedC++ wrapper around Uniscribe. > I cant escape either of ManagedC++ or C# Interop, which requires maximum > permission I believe. However what my library does and the function it > exposes are all harmless (No pointer exposed, only bound checked .NET > array) > > How to manage that? Thanks!
Speaking of that, with a strong named library in the GAC, is it possible to grant high permission to the library itself while requiring little permission from calling code? Show quote "Pieter Philippaerts" <pieter.nospam@mentalis.org> wrote in message news:%23b%23yM7kkGHA.1272@TK2MSFTNGP03.phx.gbl... > Check out the PermCalc tool > [http://msdn2.microsoft.com/en-us/library/ms165077.aspx] that ships with > the .NET framework SDK. This will give you a good idea of which > permissions your assembly needs, but if you're interoping in C#, you > typically will need the Unmanaged Code security permission (which is > indeed the most permissive permission). > > Regards, > Pieter Philippaerts > > > "Lloyd Dupont" <net.galador@ld> wrote in message > news:%23gIvzuekGHA.1260@TK2MSFTNGP05.phx.gbl... >> FxCop advise me to assign some security to my library, with this warning: >> http://www.gotdotnet.com/team/fxcop/docs/rules.aspx?version=1.35&url=/Usage/AssembliesShouldDeclareMinimumSecurity.html >> >> I should confess that I have little knowledge about this, never done it >> before. >> >> And I face the following conundrum: >> >> On one hand my component won't use any system resource (no disk access, >> no socket access, etc...) >> >> On the other hand one of my DLL is a ManagedC++ wrapper around Uniscribe. >> I cant escape either of ManagedC++ or C# Interop, which requires maximum >> permission I believe. However what my library does and the function it >> exposes are all harmless (No pointer exposed, only bound checked .NET >> array) >> >> How to manage that? > > "Lloyd Dupont" <net.galador@ld> wrote in message Yes, that's why the GAC is there for... :-)news:OTsSN%23nkGHA.4884@TK2MSFTNGP03.phx.gbl... > Thanks! > > Speaking of that, with a strong named library in the GAC, is it possible > to grant high permission to the library itself while requiring little > permission from calling code? Starting from .NET 2.0, all assemblies that are placed in the GAC are granted full trust (so they can basically do anything they want). Other assemblies running in lower privilege domains (ie assemblies from the internet or intranet zone) can call into your GAC library without requiring any special permission (unless your library demands a specific permission). Of course, it's your job as a class library designer to make sure that your API is safe. One gotcha though: if you want to make your library available to partially trusted callers, make sure you specify the AllowPartiallyTrustedCallers attribute in the AssemblyInfo file. Regards, Pieter Philippaerts Thanks Pieter!
In fact I never really pay attention to that. But as I'm trying to develop a library which I intend to sell as a component, thanks to FxCop, I came to pay attention to these, ahum, little detail... Show quote "Pieter Philippaerts" <pieter.nospam@mentalis.org> wrote in message news:%23jpoKgtkGHA.3848@TK2MSFTNGP04.phx.gbl... > "Lloyd Dupont" <net.galador@ld> wrote in message > news:OTsSN%23nkGHA.4884@TK2MSFTNGP03.phx.gbl... >> Thanks! >> >> Speaking of that, with a strong named library in the GAC, is it possible >> to grant high permission to the library itself while requiring little >> permission from calling code? > > Yes, that's why the GAC is there for... :-) > Starting from .NET 2.0, all assemblies that are placed in the GAC are > granted full trust (so they can basically do anything they want). Other > assemblies running in lower privilege domains (ie assemblies from the > internet or intranet zone) can call into your GAC library without > requiring any special permission (unless your library demands a specific > permission). Of course, it's your job as a class library designer to make > sure that your API is safe. > > One gotcha though: if you want to make your library available to partially > trusted callers, make sure you specify the > AllowPartiallyTrustedCallers attribute in the AssemblyInfo file. > > Regards, > Pieter Philippaerts > > Hi
Don't forget that the assembly in the GAC may need some assert statements, as otherwise the whole call stack will be checked. MS recommend that you make a demand before making an assert, and a common design pattern is to create a custom permission for this. Here's some samples from patterns and practices: http://msdn.microsoft.com/practices/compcat/default.aspx?pull=/library/en-us/dnnetsec/html/THCMCh09.asp 'sandboxing' is actually used for calling components that don't have the APTCA attribute, but the example will show you how to use Assert to stop the stack walk. Hope this helps Show quote "Pieter Philippaerts" wrote: > "Lloyd Dupont" <net.galador@ld> wrote in message > news:OTsSN%23nkGHA.4884@TK2MSFTNGP03.phx.gbl... > > Thanks! > > > > Speaking of that, with a strong named library in the GAC, is it possible > > to grant high permission to the library itself while requiring little > > permission from calling code? > > Yes, that's why the GAC is there for... :-) > Starting from .NET 2.0, all assemblies that are placed in the GAC are > granted full trust (so they can basically do anything they want). Other > assemblies running in lower privilege domains (ie assemblies from the > internet or intranet zone) can call into your GAC library without requiring > any special permission (unless your library demands a specific permission). > Of course, it's your job as a class library designer to make sure that your > API is safe. > > One gotcha though: if you want to make your library available to partially > trusted callers, make sure you specify the > AllowPartiallyTrustedCallers attribute in the AssemblyInfo file. > > Regards, > Pieter Philippaerts > > >  |
|||||||||||||||||||||||
Other interesting topics