On Thu, 2005-10-13 at 23:45 +0200, Marcus Brinkmann wrote: > I always wondered about something related to weak. What you say > applies, presumably, to all kernel objects, and to a certain set of > "standard objects". > > But what if I introduce a new type of objects, where even a "read > only" capability supports "writish operations"? Can I then break out > of confinement with the support of the server providing that > capability?
The weak restriction is a conservative restriction: weak(endpoint-cap) => void-cap > The actual question I think I am asking is if the interpretation of > read/write/weak only applies to the standard objects, or if it can be > extended to new object types, and what happens if you have object > types that don't fit this pattern at all. It cannot be extended in this way. The problem is that the kernel has no way to know which objects can be trusted in this fashion. In principle, it would be possible to introduce "privileged endpoints" s.t. there might be certain servers that the kernel might recognize as trustworthy. There are three problems with this in practice: 1. It is very quickly abused. 2. In consequence, not even a really stupid security evaluation would pass with this feature present. 3. It is the kind of privileged, non-extensible policy that Alfred (and I) think are a really horrible idea. In GNOSIS, KeyKOS, EROS, CapROS, and Coyotos, the historical rule was: The kernel shall never rely on user-mode code -- even *trusted* user mode code such as the space bank -- for its correctness. In EROS and CapROS, we have relaxed this to permit user-mode drivers. Except where we sandbox these, we consider these to be part of the kernel where trust issues are concerned. HOWEVER My description of the constructor confinement test was simplified. The one that I described is the one that is always used in practice, but there is another one that will probably resolve your concern even though (I predict) you will never ever use it. The one that I described is the one that I think of as the "absolute confinement" test. However, the definition of confinement does not require absolute confinement. It only requires that there be no *unauthorized* holes. In KeyKOS, the test was: constructor->isConfined(capset-of-authorized-exceptions) where capset is yet another user-mode object that is recognized by the constructor. The KeyKOS version of the constructor (which was called the "factory", which will answer one of Guy's offline questions) operated a little differently than the EROS version. During fabrication, unconfined capabilities are added to a capset that is held by the constructor. On confinement check, the user-supplied capset and the constructor's capset are compared by a set difference operation. If the set difference: ConstructorCapSet - UserCapSet is non-empty, then the yield is unconfined. In EROS, we did not implement this for two reasons: 1. In practice, it had been used rarely and we had not yet seen *any* motivating case in EROS. 2. U.S. Patent 4,584,639 http://www.cis.upenn.edu/~KeyKOS/Patent/Patent.html The problem was that we were unable to circumvent this aspect of the patent using documentable prior art (though in hindsight, I now know that prior art did exist). Thankfully, the patent has now expired. The KeyKOS team threw a big party when that patent died. Today, I would not hesitate to implement the complete check if it ever became useful. An interesting side-light: the capability set can be placed in a mode where it will not return capabilities, and it will only answer yes or no to set difference operations on other capability sets. This allows an administrator to construct a set of capabilities that are deemed safe in the local environment by administrative decree (e.g. for locally connected printers). The cool part is that doing this doesn't give unauthorized users access to those devices. A given user or client program, of course, is free not to use this capability set, or to construct their own opaque set and perform an opaque set union, thereby augmenting the trusted set. Needless to say, most users probably shouldn't be encouraged to do this, because in practice *all* of their trust judgments are going to turn out to be dangerous to them. shap _______________________________________________ L4-hurd mailing list L4-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/l4-hurd