Ok. . . I think this is where I need to begin -
3 assemblies
MyApp.Utilities.dll - strongnamed
MyApp.exe - strongnamed
MyApp.Permissions.dll - strongnamed with StrongNameIndentity LinkDemand applied (this prevents linking to an assembly that doesn't have my strong name and applying my permission to an imposter)
In MyApp.Permissions.dll, define my own action enumeration which are asserted/evaluated via sealed extensions of CodeAccessPermission and CodeAccessPermissionAttribute, implementing the appropriate abstracts and overriding if needed (IPermission.Demand perhaps )
MyApp.exe asserts the permissions when an action is needed.
MyApp.Utilities demands the permissions for the appropriate action via the attribute.
Have I got that right so far
CAS some more. . . .
Hot Topic
- Converting from CDO.Message to System.Net.Mail
- User Authentication ASP/SQL
- bug in Int32.Parse
- Least common denominator
- inline query vrs sqlcommand duration
- XmlRootAttribute and CodeDom
- Creating a temporary Directory
- Is a hyperlink containig the word google seen as non accessible?
- FCL exposed to COM
- DateTime.Parse problem (IndexOutOfRange Exception)
.NET Development
- Mass mailing in C#.
- Windows Service using Sockets
- .NET on Linux
- I dont khow how to display the XML file "professional" way
- Get CaptionFont in VB.NET
- WSE3 : Is MTOM supposed to work?
- Creating Arrays in Tables
- ByVal or ByRef
- why does this crash it's too small to crash? :)
- helloworld app generates "System.Security.SecurityException" occurred in mscorlib.dll
CAS some more. . . .
Mike Southerland
-Shawn
snaill
If I have a library that factories initialized IDBConnections for use by other assemblies, I have to validate that the consuming assembly is authorized to use the factory.
There is nothing to prevent a rogue from referencing my assembly in another application and using it, that is without implementing CAS.
Or am I missing something
socalmp
Yep. You should derive from CodeAccessPermission and also implement IUnrestrictedPermission. You then need to override the abstract methods from CodeAccessPermission, but not Deny. CAS does the work of calling the appropriate methods in your permission to determine if a demand should succeed or not. Simpl,y supplying IsSubsetOf and friends should be enough for CAS. Then you need to override the XML serialization code as well. You'll also need to ensure that your assembly recieves FullTrust (by registering in the full trust list). There's a whitepaper on the process here:
http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnnetsec/html/HTCustEncr.asp
-Shawn
Pete Smith
-Shawn
rohits
We need to do a thorough analysis of the assembly interfaces to identify possible threats and educate the administrators of our applications as to what needs to be done.
Again, there is nothing proprietary on our part but we need to assure our client base that sensitive data they persist is secure.
So as far as full trust. . . things can only run at full trust if the system administrator allows it, right And that trust can't span machines, right I don't care if my user runs full trust if they understand the implications.
This was one of those things that woke me up in the middle of the night! And it has me going back looking at our COM interfaces!
I am reading Programming .Net Security [Freeman & Jones, O'Reilly] and it is soooo confusing.
Thanks. . .
JohnGreenan
yeah, it dawned on me that I can't have Connections/Commands/Adapters/Transactions freely crossing assembly lines as the assemblies can be loaded up and used to get the connections strings out of them.
Is this a valid concern or have I missed something in my design
jude_nishamal
Again. . . thanks for your comments.
If you have a moment, take a look at this visio diagram export:
http://www.obj-tec.com/connmgmt/connectionmgmt.htm
The box labeled Connection Management Services manages a Key/Value list of Connection Definitions. The idea being similar to the old ODBC Data Sources.
I envision the interactions on the left, top and right sides of the Connection Management Services being 'qualified' appdomains.
The qualities will be based on Strong Name Identity, Publisher, Roles and a distinct set of Custom Permissions.
The qualities can be classified as Admin, Utility and Data Access based on a combination of the custom permissions.
The goal is all four components can run on one machine (Desktop) or distributed (Enterprise). The Data Access Services box could also be further decomposed across different layers but that is for another day. The only constraint that makes any logical sense being that if the user interface is on a seperate machine, it would be silly to have any other component, besides the administrative interface, on the same machine.
As far as using 2.0, it is probably going to be a couple of years before we start implementing a solution with that. Our client base is the DoD and their contractors. They haven't even approved .Net 1 yet, though we expect it in the next 6 months. (see my post here)