|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Securing a control assembly against use of foreign assembliesI know how to use the StrongNameIdentityPermission attribute to secure an assembly against callers which have no strong name with the given public key. Securing controls is problematic, since the Visual Studio (7) designer has no strong name (even if it would, the public key would be another). So dragging a secured control from the tooolbar results in a SecurityException. The only workaround I know is, to only secure the public methods of the control (except InitializeComponent). But this does not satisfy the security guidlines of the company I work for. Does anyone know another workaround to secure controls in a way that allows the using in the VS designers? Is this problem fixed in 2.0? Thanks in advance Juergen Bayer "Jürgen Bayer" <jb42[nospam]@gmx.de> wrote in message StrongNameIdentityPermission demands are not particularly strong protection news:OczxmTCmFHA.2156@TK2MSFTNGP14.phx.gbl... > Hi all, > > I know how to use the StrongNameIdentityPermission attribute to secure an > assembly against callers which have no strong name with the given public > key. Securing controls is problematic, since the Visual Studio (7) > designer has no strong name (even if it would, the public key would be > another). So dragging a secured control from the tooolbar results in a > SecurityException. The only workaround I know is, to only secure the > public methods of the control (except InitializeComponent). But this does > not satisfy the security guidlines of the company I work for. against misuse since they are easily bypassed. Do the security guidelines specifically indicate that strong name demands are to be used, or would an alternate protection mechanism (e.g.: licensing) be satisfactory? > Does anyone know another workaround to secure controls in a way that License verification is frequently used for controls. However, if you're > allows the using in the VS designers? locked into use of strong name verifications by company guidelines, you could use a similar approach to that used by most licensing: check if your control is in a designer host before issuing the demand. > Is this problem fixed in 2.0? Yes and no. In 2.0, fully trusted code will automatically pass all identity permission demands. Since the code calling your InitializeComponent method from the designer will most likely be fully trusted, it will pass the demand, and this particular problem won't manifest. However, since all fully trusted code will pass the demand, your strong name identity verifications will probably become essentially useless... Show quoteHide quote > > Thanks in advance > > Juergen Bayer > Many Thanks for your response.
Checking if my control is in a designer host before issuing the demand does not work since the StrongNameIdentityPermission is missing a LinkDemand method. The Demand methode results in an exception since the origin caller (mscorlib?) is not signed with a applicable strong name. The 2.0 bypassing of all demands on fully trusted code makes StrongNameIdentityPermission really useless. So we will implement a License verification. Show quoteHide quote "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im Newsbeitrag news:eY9CnlCmFHA.2472@TK2MSFTNGP15.phx.gbl... > "Jürgen Bayer" <jb42[nospam]@gmx.de> wrote in message > news:OczxmTCmFHA.2156@TK2MSFTNGP14.phx.gbl... >> Hi all, >> >> I know how to use the StrongNameIdentityPermission attribute to secure an >> assembly against callers which have no strong name with the given public >> key. Securing controls is problematic, since the Visual Studio (7) >> designer has no strong name (even if it would, the public key would be >> another). So dragging a secured control from the tooolbar results in a >> SecurityException. The only workaround I know is, to only secure the >> public methods of the control (except InitializeComponent). But this does >> not satisfy the security guidlines of the company I work for. > > StrongNameIdentityPermission demands are not particularly strong > protection against misuse since they are easily bypassed. Do the security > guidelines specifically indicate that strong name demands are to be used, > or would an alternate protection mechanism (e.g.: licensing) be > satisfactory? > > > >> Does anyone know another workaround to secure controls in a way that >> allows the using in the VS designers? > > License verification is frequently used for controls. However, if you're > locked into use of strong name verifications by company guidelines, you > could use a similar approach to that used by most licensing: check if your > control is in a designer host before issuing the demand. > > >> Is this problem fixed in 2.0? > > Yes and no. In 2.0, fully trusted code will automatically pass all > identity permission demands. Since the code calling your > InitializeComponent method from the designer will most likely be fully > trusted, it will pass the demand, and this particular problem won't > manifest. However, since all fully trusted code will pass the demand, > your strong name identity verifications will probably become essentially > useless... > > >> >> Thanks in advance >> >> Juergen Bayer >> > > "Jürgen Bayer" <jb42[nospam]@gmx.de> wrote in message Well, strictly speaking, it's not really missing it. Instead, the approach news:OkjbndDmFHA.3832@TK2MSFTNGP10.phx.gbl... > Many Thanks for your response. > > Checking if my control is in a designer host before issuing the demand > does not work since the StrongNameIdentityPermission is missing a > LinkDemand method. of a link-time demand doesn't work when called imperatively since the linking has already happened by the time the code could get called. > The Demand methode results in an exception since the origin caller There are ways around this, but nothing that will really get you a better > (mscorlib?) is not signed with a applicable strong name. result than using a licensing approach instead. > The 2.0 bypassing of all demands on fully trusted code makes Probably a good idea. <g>> StrongNameIdentityPermission really useless. So we will implement a > License verification. Show quoteHide quote > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> schrieb im > Newsbeitrag news:eY9CnlCmFHA.2472@TK2MSFTNGP15.phx.gbl... >> "Jürgen Bayer" <jb42[nospam]@gmx.de> wrote in message >> news:OczxmTCmFHA.2156@TK2MSFTNGP14.phx.gbl... >>> Hi all, >>> >>> I know how to use the StrongNameIdentityPermission attribute to secure >>> an assembly against callers which have no strong name with the given >>> public key. Securing controls is problematic, since the Visual Studio >>> (7) designer has no strong name (even if it would, the public key would >>> be another). So dragging a secured control from the tooolbar results in >>> a SecurityException. The only workaround I know is, to only secure the >>> public methods of the control (except InitializeComponent). But this >>> does not satisfy the security guidlines of the company I work for. >> >> StrongNameIdentityPermission demands are not particularly strong >> protection against misuse since they are easily bypassed. Do the >> security guidelines specifically indicate that strong name demands are to >> be used, or would an alternate protection mechanism (e.g.: licensing) be >> satisfactory? >> >> >> >>> Does anyone know another workaround to secure controls in a way that >>> allows the using in the VS designers? >> >> License verification is frequently used for controls. However, if you're >> locked into use of strong name verifications by company guidelines, you >> could use a similar approach to that used by most licensing: check if >> your control is in a designer host before issuing the demand. >> >> >>> Is this problem fixed in 2.0? >> >> Yes and no. In 2.0, fully trusted code will automatically pass all >> identity permission demands. Since the code calling your >> InitializeComponent method from the designer will most likely be fully >> trusted, it will pass the demand, and this particular problem won't >> manifest. However, since all fully trusted code will pass the demand, >> your strong name identity verifications will probably become essentially >> useless... >> >> >>> >>> Thanks in advance >>> >>> Juergen Bayer >>> >> >> > > 
Other interesting topics
Authorization against AD using MC++
sn.exe exit code documentation ? Why defaultcredential doesn't use the impersonated user? Java security api - DCE 128bit encryption with .NET SecurityException: Request Failed on CreateInstanceAndUnwrap HttpWebRequest.GetRequestStream - Trust Failure In Windows Service Forms Authentication Not Redirecting To Login Page Decrypt file in VB6 encrypted in vb.net Runtime error when running caspol w/ -pub -hex Propagate Credentials from Internet Explorer Host Instead of Defau |
|||||||||||||||||||||||
