Hi,
I start learning\working with security and I found out that full-trust apps
are like the
Masters of my server.

for example, I have an ASP.NET web site which has ASP->BL->DAL, and I would
like to defend my DAL from malicious users, I'll put the
StrongNameIdentityPermission on the DAL's classes (each and each of them),
and I am pretty sad to hear that I only defend from partial-trust app.

If I'll have another site on the same machine, and they will have full trust
(which is the default) they could still access my DAL?!

so why should I work so hard?

my questions are?
1) am I right? Is that Fully-trusted apps can access Components with
StrongNameIdentityPermission protection?
2) If this is true? so how can I defend my DAL against those hackers\evils?
3) If this is true? isn't it a bug? Is there any reason behind this idea? I
am sending DLL to my partners, but I want one of the method for my only
usage, so I'll defend it using the StrongNameIdentityPermission, but hey,
again they can laugh out loud, of my stupidity... they can still access it.
(so why should I use it from the first place)?

Thanks alot.
Shani.

Show quote Hide quote That depends somewhat on the configuration (e.g.: it is possible to set up
user security to prevent this), but chances are that a shared hosting
provider that allows full trust isn't likely to be taking the necessary
measures.  If you are concerned about the possibility of exploit by other
applications in shared hosting, you may want to consider moving either to
dedicated hosting or to a shared hosting environment where low trust is
strictly enforced.


Is adding SNIP demands really such hard work? <g>

On a somewhat more serious note, there's nothing you can do to prevent
exploit by fully trusted code running on the same machine (assuming that
code runs under a user context capable of running or reading your code).
However, identity permission demands do offer protection against partially
trusted code, so they're not completely useless.  They can also help you
distinguish between public and semi-public APIs, thereby potentially helping
you decide what breaking changes you can make to public types and members
during later maintenance cycles.  Unfortunately, the latter goal won't be
met if your code may be consumed by legitimate fully trusted "outside"
callers, so you may wish to consider using InternalsVisibleToAttribute
instead of SNIP demands.


Under .NET 2.0, SNIP demands provide no protection against fully trusted
callers.  They didn't provide any real protection against malicious fully
trusted callers in 1.x either, but they did at least fire a security
exception when called from full trust, which meant that they served as "no
tresspassing" signs that would probably be respected by most legitimate full
trust callers.


Don't allow them physical access to your code.  In a shared hosting ASP.NET
scenario, ensure that you host with a provider that maintains a strict low
trust policy.  If you can't find one, move to dedicated hosting (assuming
the added security is worth the additional cost).


It's by design.  See
http://blogs.msdn.com/eugene_bobukh/archive/2005/05/06/415217.aspx for the
first announcement of this change.  FWIW, I'm not particularly fond of the
new behaviour either
(https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=94713),
but we don't have much choice but to live with it now...

Its only utility now is to protect against partially trusted callers.
However, identity permission demands never protected against willful abuse
by highly privileged callers, who could always bypass the demands using
workarounds like disabling CAS or spoofing assembly evidence.  If you want
to protect your code from your partners, you would need to use an
architecture that keeps your code out of their hands.  Moving your sensitive
code into a web service that you host is one possible approach for this sort
of thing.

Using remoting features inside a .NET applet loaded in a tag object
Configuration Tool missing
Sending signed and encrypted email.
.NET 2.0: SetAccessControl wipe out inherited ACEs
remote registry access issue on Vista RC1
VS 2005 publish and app.config encryption problem
BinaryFormatter.Deserialize and Smart Clients
Drag and Drop Outlook email to Dot Net Framework application?
Problems with code access security policy
Security Windows Application and Web application