dotnet security: code access security with URL condition -- dotnet security

You're in the

dotnet security

group:

code access security with URL condition

code access security with URL condition

Sankar Nemani
8/24/2004 9:49:18 AM

dotnet security: Hi
We have two virtual directories in which our .NET controls reside. We
host these controls in IE. These controls need full trust permission set. We
tried to create a codegroup that has a URL condition http://localhost/* and
gave full trust permission and tested by opening IE on the same machine as
the server (that is why localhost should have been OK). Some parts of the
controls worked but we got SecurityExceptions for others. We kept getting
SecurityExceptions in one part or the other until we created 6 code groups
with URL conditions
http://localhost/*
http://MACHINENAME/*
http://127.0.0.1/*
http://localhost/VirtDir1/*
http://MACHINENAME/VirtDir1/*
http://127.0.0.1/VirtDir1/*
and gave full trust for all these code groups. The computer is not on any
network. When it was hooked up to the a network, we didn't need all 6 code
groups. It seems like the code access security mechanism is not able to
figure out localhost,MACHINENAME and 127.0.0.1 as the same URL.
I would like to understand how .NET applies these permissions and if there
are any resources that discuss these things in detail.
TIA
Sankar Nemani

Re: code access security with URL condition

Sankar Nemani
8/24/2004 1:08:55 PM

So is there a place that discusses how the .NET framework finds the code
group when more than one code group exist?

[quoted text, click to view]

Re: code access security with URL condition

Nicole Calinoiu
8/24/2004 3:37:28 PM

UrlMembershipCondition, which is the class responsible for testing whether
evidence matches a code group URL condition, does not account for the
multiple URLs that could be used to reach the same site. My guess would be
that while you were working offline, you used the various localhost, machine
name, and 127.0.0.1 addresses in such a way as to make some of the controls
source from each one. As for needing the two root/* and root/virtdir1/*
forms, I wonder if you really need all 6 or just the 3 root variants of the
more suitable of the two.

Either way, instead of spending time worrying about a purely dev-time
configuration problem that you've already solved, perhaps it might be more
worthwhile to spend some time figuring out how to get the controls to run
without full trust...

[quoted text, click to view]

Re: code access security with URL condition

shawnfa NO[at]SPAM online.microsoft.com (
8/24/2004 10:11:11 PM

You can find lots of this information on our MSDN site, for a good intro look at the Security Policy topic of the following article:
http://msdn.microsoft.com/library/en-us/dnnetsec/html/netframesecover.asp?frame=true#netframesecover_topic7

Basically how it works is that on each policy level is a tree of code groups. Each code group has a membership condition, a permission set,
some child code groups, and a way to combine multiple sets. Starting from the root code group, the policy evaluation checks the membership
condition of the code group that is currently being evaluated. If the evidence of the assembly being evaluated matches the membership condition,
then we proceed to the child code groups, combining all children code groups with the combination mechanism specified by the code group itself.
(If that wasn't unclear enough ...... almost all code groups are UnionCodeGroups, which simply take the union of all the permission sets of their child
code groups that also match the evidence).

So on each policy level, we end up unioning all the code groups that match (unless you hit a LevelFinal or Exclusive group), leaving us with four
permission sets, one per level. Then we intersect all four of these sets and end up with the final assembly grant.

-Shawn
http://blogs.msdn.com/shawnfa

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they
originated.
--------------------
[quoted text, click to view]

Re: code access security with URL condition

Sankar Nemani
8/25/2004 10:01:56 AM

Yes indeed it is "unclear". But this is a good starting for me to understand
how CASPol works.
Thanks a bunch
Sankar Nemani
[quoted text, click to view]
UnionCodeGroups, which simply take the union of all the permission sets of
their child
[quoted text, click to view]
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09
..phx.gbl
[quoted text, click to view]

Re: code access security with URL condition

shawnfa NO[at]SPAM online.microsoft.com (
8/25/2004 9:12:15 PM

Sorry about the confusing explanation. Reread the last paragraph of my post, which sums it up in the general case:

So on each policy level, we end up unioning all the code groups that match (unless you hit a LevelFinal or Exclusive group), leaving us with four
permission sets, one per level. Then we intersect all four of these sets and end up with the final assembly grant.

To clear up one other thing -- CASPol is simply the commandline tool that is used to modify policy settings. CAS (without the -pol) is the code
access security system that includes policy evaluation (what I was describing below).

-Shawn
http://blogs.msdn.com/shawnfa

--

This posting is provided "AS IS" with no warranties, and confers no rights.
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they
originated.
--------------------
[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the dotnet security group.

home · blog · groups

Questions? Comments? Contact the dn