On Mon, 2006-05-29 at 13:37 +0200, Pierre THIERRY wrote: > Scribit Bas Wijnen dies 29/05/2006 hora 11:16: > > - There are two types of restricted storage: read-only, and no-access. > > Both types do not provide access to the capabilities of the running > > program. > > I don't see why there should be an automatic distinction between data > and capabilities pages. This breaks the Flexibility requirement. I'll > suggest the following permissions, that could be applied to data or caps > or both: > > - read/write > - read > - none
Here is why: Read permission on capabilities implies transitive write permission. Therefore, if you want to be able to build programs whose write access is restricted, you *must* be able to restrict their read accesses to capabilities. Specifically, consider: Process P holds RO cap to CapPage CP CapPage CP slot 5 holds RW cap to some page PG P can write outward by tmp := CP[5]; ;; map tmp into address space ;; store to that page This is the entire reason for the WEAK access restriction in EROS. Without this, you cannot do confinement cost-effectively (it can be done, but requires deep-copy of state at constructor fabrication time). > I wonder if a write notice flag could be interesting. If that flag was > activated, some process would be notified when the corresponding pages > were written. That could allow a parent to write it's child's storage, > but still enable the integrity verification of the child by another > process (there would be a need for an integrity protocol, though). This notice generally comes too late to be any good -- the horse has already left the barn. Also, it requires dynamic monitoring that is generally agreed to be too expensive in practice. A comparable technique has sometimes been used to handle dynamic security level tainting in MLS systems. > In general, some capabilities typically given by the constructor need > only to be read-only, for example the TCB ones, like to the > meta-constructor and the constructor. This is incorrect. Both of these are "entry" capabilities (i.e. capabilities to send to a process that implements some object). A "send" capability can never be considered read-only by the kernel, because the kernel has no way to know whether the behavior of the server is actually read-only. > > - When a user starts a sub-Hurd (or debugs a program in some other > > way), it must be impossible for the program, or any of the programs it > > spawns on its own storage, to become restricted. > > Then again, this breaks Flexibility. I have seen several references to the "Flexibility" design goal. Is this goal described somewhere? shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
