On Tue, 2005-10-25 at 00:28 +0200, Bas Wijnen wrote: > I would expect a constructor to take exactly these steps. What I'm saying is > that putting the steps in a constructor and not in the instantiator is a level > of indirection, so without a constructor you are starting the process more > directly.
The constructor *is* the instantiator. There is no added level of indirection. Perhaps it would help to think of a multiply instantiated task server, where each task server is responsible for instantiating exactly one type of process. That would be a constructor. > > > You would, since the task server is a trusted server, and the address > > > spaces it gives out are guaranteed not to leak. > > > > It cannot make this guarantee without doing all of what the constructor > > does. > > I don't see why not. What the task server does is simply "split these pages > owned by the requestor off into a new address space". It doesn't alter the > data in > them, and in particular it doesn't add any capabilities (well, I guess it > needs 1 to start negotiations with its parent). What guarantees does the task server make about any initial capabilities that are held when the process is created? How does it test to ensure that these guarantees are met? > Now I expect > the parent to add some capabilities, after which the child can "really" start > running. If the parent didn't add unconfined capabilities, the child will be > confined. By definition, any capability the parent adds is considered an authorized capability, and therefore confined. > > On Mon, Oct 24, 2005 at 03:37:35PM -0400, Jonathan S. Shapiro wrote: > > On Mon, 2005-10-24 at 11:57 +0200, Bas Wijnen wrote: > > > Repeating this to make sure I understand what you mean: Processes may have > > > private information from more than one source, and none of these sources > > > is > > > entitled to see it all. > > > > It is more than that. Yes, none of the sources is entitled to see it > > all, but also, the creator of the process is not entitled to see it all. > > I think we mean different things by "parent". I am using the word for the > process which fills the initial memory of a process with code. In case of > EROS, every parent is a constructor (except the parent of a constructor, which > is the meta-constructor, and the parent of the meta-constructor, which > probably doesn't exist). Yes. Thank you. We were indeed using the term "parent" differently. In EROS: the metaconstructor is considered to be simply another constructor. As you suspect, it is one of the primordial processes. The metaconstructor is not built from a constructor. > What you seem to mean with it is what I call the instantiator, in EROS the one > who calls the constructor. Yes. > The violation of the principle of least authority I was talking about occurs > when the parent can inspect the memory of its child. Yes, that would indeed violate least authority. It sounds like we are in agreement about this. > However, the parent of > ConfirmPassword is the ConfirmPasswordConstructor, which is also trusted code. > And since a constructor is probably not too complex, it may not be a problem > if it could potentially access private data, because we know that it doesn't. > In other words, we can consider the constructor code (the part which is > inserted by the meta-constructor, not the part which is inserted in the new > program) part of the TCB, which makes having access to private info no > problem. The constructor code is indeed part of the TCB. It is a case of "trusted code that manipulates untrusted state" where the untrusted state is the components that will go into the newly created process. Ignoring comments and blank lines, the constructor is 360 lines of code. The metaconstructor is only 175 lines. > > Actually, the user cannot replace it either, because the agent has > > access to the real password database and this must be protected. At > > most, the user can choose from a selection of system-trusted > > authentication tools. > > I'd split the process up in two parts: the actual function, which returns a > bool and cannot be replaced, and the front-end which is presented to the user > for typing in the password. The latter should be customizable (and it should > be customized, too). Unfortunately, the front end cannot safely be customized either. The issue is that the front end has access to a trusted path to the window system. If the front end is compromised, then the trusted path is compromised. If the trusted path is compromised, then the user no longer has any ability to have any confidence at all about where their input is going. > > > Since fake programs cannot know how your > > > dialog looks, it's much harder for them to impersonate it. > > > > Nonsense. You *have* heard of screen dumps, haven't you? > > Of course. But I'm assuming a secure system, where hardly any process will > have the right to make one. If they're allowed to open a window at all, they > still aren't allowed to inspect windows from other processes. And they > definitely aren't allowed to do that while the display is grabbed by the user > agent himself. How is a display grabbed again? That sounds like a denial of resource attack! Your faith in the difficulty of simulating a dialog box is touching. Unfortunately, there is overwhelming real-world evidence that it is misplaced. You are proposing a form of security by obscurity. It doesn't work. > One more thing: In a different e-mail (which I can't find anymore), you asked > why I insist on giving the parent access to the memory of the child... I think this was a result of our confusion about the term "parent". shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
