Hide Interface?

  • Thread starter Thread starter pnp
  • Start date Start date
P

pnp

Is there an attribute (or another method) to hide an interface (in a dll)
from being seen from the object browser while browsing a dll?

Thanks in advance,
pnp
 
The problem is that it has to be public because it is being used by other
assemblies... The need to hide it is for security reasons.

Can anything be done?
 
pnp,

Even if you were able to hide it from an object browser, the metadata
for the interface could still be read (if you have to make it public, then
there is nothing you can do about this).

However, if you are dealing with object browsers that use the Reflection
API, then you can probably place a ReflectionPermission attribute on your
types, denying the permission. This should offer some sort of protection.

Hope this helps.
 
I'll give it a try, thank you both.


Nicholas Paldino said:
pnp,

Even if you were able to hide it from an object browser, the metadata
for the interface could still be read (if you have to make it public, then
there is nothing you can do about this).

However, if you are dealing with object browsers that use the Reflection
API, then you can probably place a ReflectionPermission attribute on your
types, denying the permission. This should offer some sort of protection.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

pnp said:
The problem is that it has to be public because it is being used by other
assemblies... The need to hide it is for security reasons.

Can anything be done?



"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us>
wrote
in message news:[email protected]...
Click to expand...
Click to expand...
 
Could you post me an example because I didn't have any luck by trying it my
self?


Nicholas Paldino said:
pnp,

Even if you were able to hide it from an object browser, the metadata
for the interface could still be read (if you have to make it public, then
there is nothing you can do about this).

However, if you are dealing with object browsers that use the Reflection
API, then you can probably place a ReflectionPermission attribute on your
types, denying the permission. This should offer some sort of protection.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

pnp said:
The problem is that it has to be public because it is being used by other
assemblies... The need to hide it is for security reasons.

Can anything be done?



"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us>
wrote
in message news:[email protected]...
Click to expand...
Click to expand...
 
Nicholas,

Do you have any evidence that denying ReflectionPermission (or any flag
subset) via an attribute at the class or member level has any effect at all?
I've tested quite a few variations on the theme (incl. imperative denial of
the permission), and I've never seen any effect on member discoverability or
accessibility via reflection.

It could be that the reflection methods are asserting the permission after
an initial stack walk to determine if the desired activity is permitted to
the callers. This would make sense in an odd sort of way since the
ReflectionPermission settings for the target can't be determined until after
it's already been loaded. That said, it would still be terribly
inconsistent with the expected behaviour for a CAS permission...

Nicole



Nicholas Paldino said:
pnp,

Even if you were able to hide it from an object browser, the metadata
for the interface could still be read (if you have to make it public, then
there is nothing you can do about this).

However, if you are dealing with object browsers that use the
Reflection API, then you can probably place a ReflectionPermission
attribute on your types, denying the permission. This should offer some
sort of protection.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

pnp said:
The problem is that it has to be public because it is being used by other
assemblies... The need to hide it is for security reasons.

Can anything be done?



"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us>
wrote
in message news:[email protected]...
Click to expand...
Click to expand...
 
Actually, ignore the second paragraph of my last post entirely. The
framework almost certainly doesn't need an assertion to prevent the deny
from working since there's no need for ReflectionPermission to be evaluated
after the target is loaded. In fact, to be consistent with the other
permissions, stack walk modifiers on the target class or member should
probably be ignored. For example, a file doesn't get to specify a modifier
for a FileIOPermission (ignoring the fact that there's no mechanism in place
for this <g>), so why should code get to specify a modifier for
ReflectionPermission? Doesn't mean I necessarily like the behaviour, but
there is a certain logic to it.



Nicholas Paldino said:
pnp,

Even if you were able to hide it from an object browser, the metadata
for the interface could still be read (if you have to make it public, then
there is nothing you can do about this).

However, if you are dealing with object browsers that use the
Reflection API, then you can probably place a ReflectionPermission
attribute on your types, denying the permission. This should offer some
sort of protection.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

pnp said:
The problem is that it has to be public because it is being used by other
assemblies... The need to hide it is for security reasons.

Can anything be done?



"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us>
wrote
in message news:[email protected]...
Click to expand...
Click to expand...
 
Back
Top