mirror of
https://github.com/danbulant/Cosmos
synced 2026-05-30 21:00:30 +00:00
132 lines
No EOL
7 KiB
Text
132 lines
No EOL
7 KiB
Text
{\rtf1\ansi\ansicpg1252\deff0{\fonttbl{\f0\fnil\fcharset0 Courier New;}}
|
||
{\*\generator Msftedit 5.41.21.2508;}\viewkind4\uc1\pard\lang3081\b\f0\fs20 Security Design \par
|
||
\par
|
||
\par
|
||
Overall\par
|
||
\b0 Capability design ..\par
|
||
\par
|
||
\par
|
||
A capability style design using references as Capabilities . In some cases we will use seperate Capability objects. \par
|
||
\par
|
||
\b\par
|
||
Are these Capabilities unforgeable / Immutable ? \par
|
||
\par
|
||
\b0 Secure Objects must have all internal or private constuctors hence cannot be created except by the assembly which contians the type we hope for the compiler to check this.\par
|
||
\par
|
||
Note references can be set to a different object of the same type but this does not invalidate the security model.\b\par
|
||
\par
|
||
\par
|
||
\par
|
||
How to do Backups ? \par
|
||
\par
|
||
\b0 Backups are performed by the file system via a Backup capability.\b\par
|
||
\par
|
||
How are Capabilies references revoked ?\par
|
||
\par
|
||
\b0 Every Secure Object has an IsNull Field that should be checked. Calling Dispose on the object will ensure all rights are revoked.\par
|
||
\b\par
|
||
\par
|
||
How are Capabilities stored and Persisted.\par
|
||
\par
|
||
\b0 Capabilities are persisted to a file that only the Persister and Backup has a Capability to access. This should be encrypted later. Note this can be compromised by physical access to the machine but so can any OS.\b\par
|
||
\par
|
||
\b0 Note the case of persisting a process and a Capability being revoked.\par
|
||
\par
|
||
\b\par
|
||
If Capabilities are references how can this be persisted ?\par
|
||
\par
|
||
\b0 An binary (or debug XML) representation will preserve references from a Key RIng. \par
|
||
\b\par
|
||
Are there Capability Objects ?\b0\par
|
||
\par
|
||
Sometimes. This is not needed but is sometimes convenient eg System.IO.File will point to an actual File with an internal pointer. The Framework requires these objects but the structure may be insecure ( eg public construtuctor) and hence wrap a secure private reference to the real object .\par
|
||
\par
|
||
\par
|
||
\b How are Capabilities Granted /Created\par
|
||
\par
|
||
\b0 Each service manages its own capabilities. The File System has all Directory and File Objects and hands out references when needed. It Can grant these to Users ,Groups , AppDomains or anything the designer desires. \par
|
||
\par
|
||
The OS Loader establishes some initial permissions eg the Service Manager requires it to load the services. However this is only on first boot / on test systems.\b\par
|
||
\par
|
||
What is in the Trusted Base ?\par
|
||
\par
|
||
\b0 This includes a number of services that are trusted by the system . It includes all unmanged code ( eg the Collector) , Plugged code and the compiler. \b\par
|
||
\par
|
||
How does the IPC work with security.\par
|
||
\par
|
||
\b0 Certain high critical services will use the Pipes with Message parsing CDC system . This hides the internal implementation and provides additional security. It is up to the service what security design to implement.\par
|
||
\b\par
|
||
\par
|
||
\par
|
||
\par
|
||
How are objects persisted\par
|
||
\par
|
||
\b0 All capabilites are persisted objects . An application can have persisted stated if all its data objects are persisted objects. Note the Store/Load and capability base class are in the same assembly and the logic is internal. Note 3 persistance modes \par
|
||
\tab - None \par
|
||
\tab - OnPropertyChanged \par
|
||
\tab - Batched ( changes based On Property Changed but batched with other object changes) \b\par
|
||
\par
|
||
How does CIL Security work.\par
|
||
\par
|
||
\b0 The Linker.Dynamic loader ensures security as private members ( CIL private = C# internal) are not exposed and hence can not be called. Hence callers cannot manipulate the assembly unless the developer inadvertantly uses the wrong access. ( For critical assemblies the message parsing CDC is recommend as it hides the internal implementation and hence makes it more secure ) \b\par
|
||
\par
|
||
Least Priviledge \par
|
||
\par
|
||
\b0 OO apps generally use privilige for a short period we should make more use of this.\b\par
|
||
\par
|
||
What secure service are there ? \par
|
||
\par
|
||
\b0 None . A lot of security breaches come from trusted services . There are no trusted services and Applications and services are treated the same. Note also there are no security layers. \par
|
||
\b\par
|
||
What does the Kernel have access to ? \par
|
||
\par
|
||
\b0 There is no kernel ( Ok you can cosnider the HAL and the schedulign primatives the kernel) \par
|
||
\par
|
||
\par
|
||
\b Access Rights \par
|
||
\par
|
||
\b0 There are really a number of Models here ( R = Reference ) \par
|
||
\par
|
||
Option1) \par
|
||
R -> Shared File Class ( with ACL)\par
|
||
\par
|
||
Option2) \par
|
||
R -> Read Rights File wrapper -> Shared file class\par
|
||
R -> Read Rights File wrapper -> file class\par
|
||
\par
|
||
\par
|
||
Option3) \par
|
||
Capability ( R + Right) -> Shared File Class\par
|
||
Capability ( R + Right) -> File Class\par
|
||
\par
|
||
Option4) Use interface of the shared ob\par
|
||
R-> (ReadOnlyInterface) Shared File Class\par
|
||
\par
|
||
\par
|
||
Option 3 is used where complex securities are needed It is just a reference with some rights. \par
|
||
\par
|
||
Option 2 may be used where access is a simple mechanism ( rights/no rights) . \par
|
||
\par
|
||
Option 4 is not viable as the interface could be case as an object and then cast as a type with different rights eg ReadWriteInterface.\par
|
||
A program must not be able to cast to object and back to version of a class with different rights and hence encapsulating the "System Object" is best.\par
|
||
\par
|
||
\par
|
||
Then again Option 2 and Option3 are similar . Note teh ReadRightsFileWrapper has rights and is a reference. The difference is with Option 3 the Capability is stored in the user program. In option 2 only the reference is in the user program. I think Option 2 will be more secure and lead to less thread contention as sometimes we dont need shared objects. \par
|
||
\par
|
||
\par
|
||
\b How does it work with persistace? \par
|
||
\par
|
||
\b0 The wrapper classes should contain NOTHING more than a internal reference and accessability should be done via public methods. These objects should be granted on a per thread bases but the Capabilities can be copied from the app domain. \par
|
||
\par
|
||
Persisting these capabilities is an issue . We have the option of storing the Read Rights File in the user App Domain or in the service. As the objects are 1/thread and persistant there is no issue with Garbage Collection. I think its best to store them in the service . When connecting to the app domain the thread can use its Keyring Capability and load all references into the threads KeyRing. Note the Keyring and the actual persistance is done in the trusted base but the types will be internal and best created by the service.\par
|
||
\par
|
||
This leads to a weird RPC style API however eg ReadableFile.Open(). Though SendMessage ( new OpenFileMessage(ReadableFIle) is possible. MMm this may be best it allows an RPC style if the service developer desires . Or a Message stle , since the methods can then be internal the service simply calls them. ie The internal design is not exposed which is always a good thing in software design. \par
|
||
\par
|
||
\par
|
||
\par
|
||
\par
|
||
\par
|
||
\par
|
||
\b\par
|
||
}
|
||
|