Re: sn.exe -Vr assembly

From: Nicole Calinoiu (calinoiu)
Date: 01/24/05


Date: Mon, 24 Jan 2005 08:12:11 -0500


"Gecko" <nada@nada.com> wrote in message
news:OpgxOsAAFHA.2728@TK2MSFTNGP10.phx.gbl...
>> Why would a user's modification of your assemblies on their own machine
>> have any effect on you?
>
> Well at first, it doesn't appear to have any effect since I do all data
> validation on the server so in theory, they could change that file until
> their hard drives burns and it should be no problem.

Good. Then why bother being annoyed by it? <g>

> However, I must be missing something because if tampering with local files
> was not an issue, why would anybody care to strong name their assemblies?

Strong names are also used for dealing with versioning issues. The strong
name public key is used to allow the CLR to distinguish between assemblies
of the same name and version, thereby avoiding the collision problems that
might otherwise occur when two software vendors attempt to publish libraries
with the same name.

>I mean, if they are logged as administrator a hacker can do just about
>anything he or she wanted strong name or not CAS or no CAS

Yes, but only on machines that he controls. Also, strong names are meant to
make certain types of tampering more difficult (but obviously not impossible
<g>), even when one does control the machine.

>, and if they are logged as regular users, you could install the files on
>GAC or on the ProgramFiles folder and the user would have no access to it
>so they can't touch it so why bother?

Well, for starters, tampering can be attempted before software is ever
installed on the target machine. In addition, even if a machine's normal
user doesn't run with elevated privilege, it's still possible for in situ
assemblies to be subjected to a tampering attempt under a sufficiently
privileged account.

You should also keep in mind that, like all potential security measures,
strong naming can only make it more difficult, not impossible, to accomplish
an attack. While one might argue that the protection offered by strong
naming is perhaps ridiculously weak, it does make it at least somewhat more
difficult to perform certain types of malicious activities. If you are
going to publish .NET assemblies, why not take advantage of every bit of
protection you can offer your clients, even if that protection may not be as
strong as you might like?

> So far I have been reading and doing very few exercise concerning Strong
> Name, CAS, DACL etc, next week I am hoping to have some time to start
> putting this knowledge to work and in the process understand this better,
> I hope thing will become clear then!!
>
> Thanks for all comments.
>



Relevant Pages

  • Re: CAS & GAC: connection?
    ... > apply with CAS and the GAC: ... assemblies will have full trust, and most assemblies in the GAC are locally ...
    (microsoft.public.dotnet.security)
  • Re: can you put a strong name assembly in a role?
    ... I hadn't fully thought out the CAS model since it ... > credentials under a similar COM+ app? ... all fully trusted assemblies will automatically pass such ... >> privileges in a SQL Server table. ...
    (microsoft.public.dotnet.security)
  • Re: Help me to undersand ???
    ... I have default settings under CAS, it means that I get Unrestricted already ... First of all when you apply security for a file/folder with with Windows ... Then for assemblies, ...
    (microsoft.public.dotnet.security)
  • RE: Could not find a part of the path - User control from within I
    ... When granting the CAS permission through strong-named codegroup, ... Are you sure whether all the assemblies used in your usercontrol(main ... evaluated as "Full Trust" permission at the client-side's .net CAS... ... usercontrol which use them reference and use them one by one and test it to ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: CAS and "My Computer" (is CAS disabled by default?)
    ... > install - totally disregards CAS? ... The default CAS does result in local ... a remotely-sourced assembly is still subject to permissions ... a full trust grant to any given assembly or set of assemblies is not ...
    (microsoft.public.dotnet.security)