Prevent DLL usage

  • Thread starter Thread starter Chris Zopers
  • Start date Start date
C

Chris Zopers

Hello,

I have two .NET dll's, one containing business logic and the other
containing data access logic.

The Business Logic DLL references the Data Access DLL.

Only the Business Logic DLL is allowed to use/reference the Data Access
DLL. No other .net assemblies may use the Data Access DLL. Is it
possible to prevent this DLL from being used by other calling assemblies
and how can this be done?

Greetings,
Chris
 
Use the sample below to use at beginning of every method of your DAL
classes:

public void test()
{
StackTrace st = new StackTrace(true);
if (st.GetFrame(1).GetMethod().ReflectedType.ToString() !=
"BLLLibrary.BLLClass")
{
throw new Exception("Can't call this method by this
assembly");
}
}
 
It requires to configure each machine the assemblies are installed.
I agree, its better and performatic. But not transparent, because requires
extra work on installation.

Anyways, those are two ways to go. To be used according the needs and
wishes. ;)
 
Thanks for your answers!

I just googled about this and indeed came across the
Assembly.GetCallingAssembly and StrongNameIdentityPermission.

I read that assemblies that run under Fully Trust wil always pass the
permission.

So does this mean that if someone created his own .net executable (and
makes it run under fully trust) he could link it directly to the Data
Access DLL and still call the methods in that dll?

Greetings,
Christian
 
Hello Chris,
Thanks for your answers!

I just googled about this and indeed came across the
Assembly.GetCallingAssembly and StrongNameIdentityPermission.

I read that assemblies that run under Fully Trust wil always pass the
permission.

So does this mean that if someone created his own .net executable (and
makes it run under fully trust) he could link it directly to the Data
Access DLL and still call the methods in that dll?
Click to expand...

Yes, that's true. In .NET 2.0 a new permission was added, the GACIdentitypermission,
you might want to look at that as well.
 
Chris said:
Hello,

I have two .NET dll's, one containing business logic and the other
containing data access logic.

The Business Logic DLL references the Data Access DLL.

Only the Business Logic DLL is allowed to use/reference the Data
Access DLL. No other .net assemblies may use the Data Access DLL. Is
it possible to prevent this DLL from being used by other calling
assemblies and how can this be done?
Click to expand...

Don't use public classes.

Use the InternalsVisibleToAttribute.
 
Aha, I didn't know the InternalsVisibleTo atribute yet, but I googled it
and it seems to do the trick too. Thanks!
 
Aha, I didn't know the InternalsVisibleTo atribute yet, but I googled it
and it seems to do the trick too. Thanks!
Click to expand...

Note that even for internal classes, there's nothing stopping a
FullTrust assembly from using reflection to instantiate your classes
and call their methods. FullTrust is precisely what the name implies -
no restrictions.

Anyway, if all you want to achieve is to give a strong hint that your
assembly should not be used directly, then internal+InternalsVisibleTo
is probably the best way, since no-one can accidentally ignore that
(unlike CAS).
 
Pavel Minaev said:
Note that even for internal classes, there's nothing stopping a
FullTrust assembly from using reflection to instantiate your classes
and call their methods. FullTrust is precisely what the name implies -
no restrictions.
Click to expand...

I'd neglected to consider instantiation through reflection. But even if
that wasn't possible, there's always decompilers or patched runtimes to
bypass security checks. The admin of the computer can always do anything.
Anyway, if all you want to achieve is to give a strong hint that your
assembly should not be used directly, then internal+InternalsVisibleTo
is probably the best way, since no-one can accidentally ignore that
(unlike CAS).
Click to expand...

Know how the runtime penalty compares, between InternalsVisibleTo and CAS?
 
I'd neglected to consider instantiation through reflection.  But even if
that wasn't possible, there's always decompilers or patched runtimes to
bypass security checks.  The admin of the computer can always do anything.
Click to expand...

Strictly speaking, FullTrust isn't the same as admin - it could be
that there's an assembly that's read-only for a particular user, but
still, his local CLR code would run under FullTrust, and so would be
able to call private/internal methods in that assembly.

Of course, he could always just copy it, and then modify the copy :)
Know how the runtime penalty compares, between InternalsVisibleTo and CAS?
Click to expand...

Not really, but if there is a difference, I'm pretty sure it's not
going to be in favor of CAS, since that one actually has to do a stack
walk to verify (the only question is whether it can optimize it away
or not when loading assemblies).
 
Back
Top