Prevent DLL usage

[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

 

[Cesar]

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");
}
}

 

[Jesse Houwing]

Hello Cesar,

A better and easier way would be to use Code Access Security and require
that the calls are coming from a specified (group) of assemblies.

This requires your assemblies to be strongly named. Use a LinkDemand assertion
to verify the permission

More information can be found here:
http://msdn.microsoft.com/en-us/lib...ions.strongnameidentitypermission(VS.71).aspx

Jesse

 

[Cesar]

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.

 

[Chris Zopers]

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

 

[Jesse Houwing]

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?

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

 

[Ben Voigt [C++ MVP]]

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?

Don't use public classes.

Use the InternalsVisibleToAttribute.

 

[Chris Zopers]

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

 

[Pavel Minaev]

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

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).

 

[Ben Voigt [C++ MVP]]

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.

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).

Know how the runtime penalty compares, between InternalsVisibleTo and CAS?

 

[Pavel Minaev]

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.

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?

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).