Re: Appl. Security Problems

From: Nicole Calinoiu (calinoiu)
Date: 05/25/05 

Date: Wed, 25 May 2005 08:31:43 -0400

"Steve B." <SteveB@discussions.microsoft.com> wrote in message
news:F7803F8D-061B-4245-AC72-0607D655475F@microsoft.com...
>I was thinking (just ideas):
> - Why does the trust assembly wizard give an error message (" Unable to
> load [path to dll]") when I identify the dll but it works for the execute
> file

If this works for the EXE, then perhaps there's some problem with the DLL
itself. Do you get the exact same result for both DLLs? Are the DLLs
located in the exact same directory as the EXE?

> - What about the location(s) of the assembly file key (path) to my
> harddrive

Not relevant. The key file is not used anymore after the assemblies are
signed at compile-time.

> - should it be the network? (see earlier post for C: path)

Absolutely not. In fact, the key you use to sign your production assemblies
probably shouldn't even be stored on your development machine. See
http://msdn.microsoft.com/library/en-us/dnnetsec/html/strongNames.asp for a
discussion of key storage techniques.

> - Why is the policy change work on my ("the developer's") machine?

Most likely because there's something different about your machine's
configuration. There are many, many possibilities, and trying to guess is
likely to be fruitless.

> - Should I test the policy change on more then one user?

Eventually, yes. However, it would be a good idea to get it working on at
least one user machine before starting to muck about with others.

> - Do I need to refence the assembly file or key in the VS project or the
> program file?

No. The key file is never needed at runtime.

> - Do I need to register the key (regsvces,exe??)

No. Again, the key is only used to sign the assembly at compile time. It's
never needed again unless you need to re-sign a delay-signed assembly, which
you don't since you're not using delay signing.

>
> Steve
>
> "Steve B." wrote:
>
>> Nicole,
>>
>> Trying to provide you as may elements of my environment as possible.
>> Please
>> - don't assume I know what I'm doing
>>
>> -->When do you see this message?
>> 1. When I try to do the policy changes NOT when the application runs.
>>
>> --> Could you please provide repro steps?
>> 2. The policy change steps are the same steps as I did on my machine and
>> are the the same as the earlier web site you referenced
>> (Machine-all_code-new..). The error message occurs after selecting
>> Strong
>> Name from comboBox and after clicking the Import button and when I
>> iidentify
>> the application dll on the shared Pub drive
>>
>> -->Exact message
>> 3. OK Message: "The Import failed. The assembly does not appear to be
>> valid."
>>
>> -->Correct versions of your compiled assemblies
>> 4. My VS compiling procedures: I Debug compile locally on my machine
>> then
>> send a Release "updated" compiled version of the application to my local
>> network (\\serverName\Pub\Business...). Then. I went to a typical users
>> machine and tried to set it up the Machine Code Group same way I did on
>> my
>> machine. My machine works fine form Pub
>>
>> -->Are any of the assemblies delay signed?
>> 5. No assemblies are delay signed
>>
>> Note: The VS solution has one exe file project and two dll projects.
>> One
>> dll is a GUI for a Access dB and the other is a Library for the dB. The
>> excute file DOES RUN on the users machine because I earlier ran the Trust
>> Assembly wizard and identified the exe file however the exe file calls
>> the dB
>> GUI and that fails to open. The Trust Assembly wizard will not trust the
>> dB
>> dll's
>>
>> Steve
>>
>> "Nicole Calinoiu" wrote:
>>
>> > "Steve B." <SteveB@discussions.microsoft.com> wrote in message
>> > news:F89770A4-781D-481D-B11B-0D1962B42E07@microsoft.com...
>> > > Nicole,
>> > >
>> > > Sorry to to keep asking these questions, however, this is the most
>> > > success
>> > > I've had in solving this problem so far.
>> > >
>> > > After following the earlier post instructions the program opened up
>> > > fine
>> > > on
>> > > my machine but when I went to another user's machine I recieved the
>> > > following
>> > > message:
>> > >
>> > > Imported failed. The assmbly does not appear to be vailid ... strong
>> > > name
>> >
>> > When do you see this message? When attempting to apply the policy
>> > changes
>> > or when attempting to run your application? If the former, could you
>> > please
>> > provide repro steps? Also, is there any chance you might be able to
>> > provide
>> > the exact message?
>> >
>> > >
>> > > What wrong?
>> > >
>> > > The following is a typical configuration I have in each Visual Studio
>> > > project (file name(s): AssemblyInfo.cs) within the solution:
>> > >
>> > > [assembly: AssemblyDelaySign(false)]
>> > > [assembly:
>> > > AssemblyKeyFile(@"C:\BusinessInformationSoftware\ADONetLibrary\obj\adoNetLibrary.snk")]
>> > > [assembly: AssemblyKeyName("")]
>> >
>> > Are any of the assemblies delay signed? i.e.: Do any have the
>> > attribute
>> > [assembly: AssemblyDelaySign(true)]? Also, are you sure that the other
>> > machine has the correct versions of your compiled assemblies?
>> >
>> >
>> >
>> > >
>> > > Steve
>> > >
>> > > "Nicole Calinoiu" wrote:
>> > >
>> > >>
>> > >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message
>> > >> news:A40F8CFA-F5E0-45B1-AC61-98B31FFECA70@microsoft.com...
>> > >> > Nicole
>> > >> >
>> > >> > Are there instructions on how trust a directorory and the files
>> > >> > within
>> > >> > it.
>> > >>
>> > >> You would simply need to use a URL membership condition rather than
>> > >> a
>> > >> strong
>> > >> name membership condition when you create the new code group.
>> > >> However,
>> > >> getting the URL right can be a bit tricky since it must match the
>> > >> URL
>> > >> used
>> > >> by the CLR to load the assemblies.
>> > >>
>> > >>
>> > >> > I have separate strong names for each project within the file VS
>> > >> > solution.
>> > >> > Should I have one strong name for the whole solution?
>> > >>
>> > >> By definition, each assembly would have a distinct strong name, so I
>> > >> suspect
>> > >> you're actually concerned about different signing keys. It is
>> > >> rather
>> > >> unusual to use a different signing key for each project within a
>> > >> solution.
>> > >> The "typical" schemes are to use a single signing key for all
>> > >> assemblies
>> > >> released by an organization, or for all assemblies released in a
>> > >> given
>> > >> product group. Since all projects within your solution presumably
>> > >> form
>> > >> part
>> > >> of the same product, they would usually be signed with the same key
>> > >> under
>> > >> either scheme.
>> > >>
>> > >> >
>> > >> >
>> > >> >
>> > >> > "Nicole Calinoiu" wrote:
>> > >> >
>> > >> >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message
>> > >> >> news:C86F5BC6-CB25-4DE9-965E-7FE50E8D986A@microsoft.com...
>> > >> >> > Local C# network application developed using VS .Net
>> > >> >> >
>> > >> >> > 1. While do some local network users able to Trust The
>> > >> >> > Assembly via
>> > >> >> > the
>> > >> >> > Control Panel .Net Framework wizard while others can not
>> > >> >> > because of
>> > >> >> > "security
>> > >> >> > policy". Why?
>> > >> >>
>> > >> >> Probably because some of them are administrators and are
>> > >> >> adjusting the
>> > >> >> assembly permissions at the machine level, whereas others are
>> > >> >> non-admins
>> > >> >> and
>> > >> >> are only allowed to attempt to adjust the permissions at the user
>> > >> >> level.
>> > >> >> The "trust an assembly" wizard will usually give the "due to your
>> > >> >> existing
>> > >> >> security policy..." result you mentioned when run at the user
>> > >> >> level.
>> > >> >> (I'm
>> > >> >> unaware of any conditions under which a user-level run of the
>> > >> >> wizard
>> > >> >> would
>> > >> >> succeed.)
>> > >> >>
>> > >> >> BTW, it is possible for non-admins to restrict assembly
>> > >> >> permissions
>> > >> >> via
>> > >> >> other tools that modify the user-level CAS policy. However,
>> > >> >> under
>> > >> >> normal
>> > >> >> circumstances, low-privilege users cannot grant increase assembly
>> > >> >> permissions beyond those granted at the enterprise and machine
>> > >> >> levels.
>> > >> >>
>> > >> >>
>> > >> >> > 2. Why do I receive the following error message when I try to
>> > >> >> > open
>> > >> >> > my
>> > >> >> > ADONet dll from the network within my local .Net application?
>> > >> >> >
>> > >> >> > "The application attempted to perform an operation not allowed
>> > >> >> > by
>> > >> >> > the
>> > >> >> > security policy. The operation required the Security
>> > >> >> > Exception. To
>> > >> >> > grant
>> > >> >> > theis application the required permission please contact your
>> > >> >> > system
>> > >> >> > administrator.."
>> > >> >> >
>> > >> >> > What do I or, my IT person, need to do to change security
>> > >> >> > policy?
>> > >> >>
>> > >> >> See http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx
>> > >> >> for
>> > >> >> instructions on how to modify the CAS policy for this scenario.
>> > >> >> See
>> > >> >> http://msdn.microsoft.com/library/en-us/cpguide/html/cpcondeployingsecuritypolicy.asp
>> > >> >> for some deployment options.
>> > >> >>
>> > >> >>
>> > >> >>
>> > >>
>> > >>
>> > >>
>> >
>> >
>> >

Quantcast