Re: HOWTO: Prevent Dynamic Loading of internal Types



....don't forget to check SecurityManager.SecurityEnabled every time - otherwise someone just turns CAS off (and isn't annoyed at all :)

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

I want to thank everyone for taking the time to answer my question.
I'll certainly return the favor if I'm able. Unless I've
misinterpreted this thread (entirely possible), I've decided to "raise
the bar" slightly by placing Henning Krause's suggestion in the
constructor of my internal class. Hopefully, I'll at least annoy
person on the other end of the keyboard ;-)

Again, this is [unfortunately] for a .NET 1.1 consumer that I'm
strongly urging to move to 2.0 (sigh).

Kindest Regards,
Michael
"Dominick Baier [DevelopMentor]"
<dbaier@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4580be63195d288c7f412d8e77f91@xxxxxxxxxxxxxxxxxxxxx

Hi,
don't get me wrong - i am not saying that raising the bar does not
make
sense. But IMO i don't think it is worthwile investing a lot in such
a
protection feature. There are too many ways to bypass it.
---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com
Hi,

seems this is a situation often encountered in security - all one
can do is to raise the bar...

Greetings,
Henning Krause
"Dominick Baier [DevelopMentor]"
<dbaier@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4580be63195d1a8c7f4035dd6e30d@xxxxxxxxxxxxxxxxxxxxx
Hi,
- and the public key you get from GetPublicKey - what does tell you
that
this is the real key - i mean you would have to verify the
signature
on
your own..
- what about SecurityManager.SecurityEnabled = false; (OK cheating
a
little because that's not supported in 2.0 anymore :)
- what about caspol -s off

believe me - there is no watertight way of doing identity
permissions for fully trusted code. You have the code on your local
machine you can do whatever you want.

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com
Hi Dominick,

next try :-)

I could get the public key from the entry assembly via
key = Assembly.GetEntryAssembly().GetName().GetPublicKey()
and do a byte-by-byte comparison between the public key loaded
from
a
resource or from the current assembly and the public key of the
entry
assembly.
On a mismatch, throw an exception.
What about that?

Greetings,

Henning Krause

"Dominick Baier [DevelopMentor]"
<dbaier@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4580be63195d118c7f4008af8d8dc@xxxxxxxxxxxxxxxxxxxxx

Hi,
sure - the calling assmbly can provide evidence on its own, also
StrongNames - it think there is even a sample on MSDN on how to
do
it
:)
Microsoft has a good reason for "disabling" identity permissions
in
2.0 for full trust code - because they provide no real security
and
are easy to bypass.
---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com
Hello Dominick,

what about this code placed in each constructor in the internal
class:
using (Stream stream = File.OpenRead("publickey.txt"))
{
buffer = new byte[stream.Length];
stream.Read(buffer, 0, buffer.Length);
}
condition = new StrongNameMembershipCondition(new
StrongNamePublicKeyBlob(buffer), null, null);
if (!condition.Check(Assembly.GetEntryAssembly().Evidence))
{
throw new Exception("invalid caller");
}
The public key token should be read from a resource of the
current
assembly, or with a call to
Assembly.GetExecutingAssembly().GetName().GetPublicKey().
This also works in full trust, but only if the method is
executed
from
an
assembly not signed with the specified public key. A call chain
of
correctly signed assembly --> invalid signed assembly -->
protected
assembly
will not be protected.
Despite the performance penalty at the creation of each instance
I
don't see any caveeats here - and the performance problem could
be
cirumvented with a factory pattern.
Any thoughts on this?
Greetings,
Henning Krause
"Dominick Baier [DevelopMentor]"
<dbaier@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4580be63195cf08c7f3f7910f6427@xxxxxxxxxxxxxxxxxxxxx
Hi,
this only works in partial trust and is a 1:1 relationship
(=does
not
scale).
There is no way to restrict fully trusted callers in .NET - and
this
is not different to any other prog languages/execution
environments
-
it is just very easy with .NET.
---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com
Hello,

you cannot prevent the loading of the assembly, but you could
sign all your code with a strong name and put a
StrongNameIdentityPermission linkdemand on every method you
want to protect.

Greetings,
Henning Krause
"Michael Primeaux" <mjprimeaux@xxxxxxxxxxxxxx> wrote in
message
news:O4O5ASCJGHA.424@xxxxxxxxxxxxxxxxxxxxxxx
How can I prevent someone from dynamically loading an
internal type from my assembly?

Kindest Regards,
Michael Primeaux



.



Relevant Pages

  • Re: HOWTO: Prevent Dynamic Loading of internal Types
    ... But IMO i don't think it is worthwile investing a lot in such a protection feature. ... Dominick Baier - DevelopMentor ... I could get the public key from the entry assembly via ...
    (microsoft.public.dotnet.security)
  • Re: HOWTO: Prevent Dynamic Loading of internal Types
    ... > fully trusted code. ... > Dominick Baier - DevelopMentor ... >> I could get the public key from the entry assembly via ... >> Henning Krause ...
    (microsoft.public.dotnet.security)
  • Re: HOWTO: Prevent Dynamic Loading of internal Types
    ... - and the public key you get from GetPublicKey - what does tell you that this is the real key - i mean you would have to verify the signature on your own.. ... Dominick Baier - DevelopMentor ...
    (microsoft.public.dotnet.security)
  • Re: Issuing X.509 Certificates
    ... Dominick Baier - DevelopMentor ... mean people give my program their public key and other characteristics of themselves and the program gives them a digital certificate which is signed by my private key. ... Of course, there are projects like OpenSSL, COM objects like CAPICOM, ...
    (microsoft.public.dotnet.security)
  • Re: Securing static files
    ... Dominick Baier - DevelopMentor ... they are kicked back to the login page. ... The user may log in with other credentials. ...
    (microsoft.public.dotnet.framework.aspnet.security)