On Mon, 2005-10-24 at 12:15 +0200, Bas Wijnen wrote: > > > Also, programs may include cleverness in predicting me which file I want > > > to open. > > > > This is not cleverness. It is betrayal. Who do you want to be in charge, you > > or the application? > > I wasn't saying it should just be allowed to open it, but I do want it to make > the suggestion. Being in charge doesn't mean I want to fire all my advisors, > even if I don't trust them. They're only advisors after all, so I can just > ignore their advice. But I do want to hear it.
I understand what you are saying. The problem here is that you have a trusted agent (the open/save-as subsystem) running untrusted code (the recommended filter function). It can be done, but it requires care. > > This specific solution does not work, but there are variations of this > > solution that could be made to work. The requirement is that the predictor > > needs to be a filter that can be proven to terminate. > > That makes sense. Or does it? A program and a predictor are a pair, they > trust each other (although they don't actually interact at all). So what > happens if the predictor fails to terminate? It would only hang the execution > of the program (which is probably blocking for the agent to provide a > capability). The problem is that the predictor filter code is running in the context of a trusted program. You may be right that non-termination is not a concern, but the open/save-as box definitely cannot run unsafe code supplied by the application. If it did, this code could invoke any capability held by the open/save-as agent, and the whole point of this exercise was that we did not trust the application to use these capabilities properly! So: this is a case where a very simple filter specification mechanism could easily handle 98% of real uses, and the right thing to do is to give up the last 2% to preserve security. You will notice, I will notice. The majority of users will never notice. > > The security problem here is that we desperately need the open/save-as agent > > to be simple. It is a program that manages an authority boundary, and these > > programs need to be programmed with the same kind of care that we have > > learned to give to setuid programs. More, actually, since we don't give > > enough care to setuid programs. > > That makes sense. So it should start the predictor from a separate process or > so, which has much less authority. Still, allowing predictors seems like a > good idea to me. The predictor needs access to the file system to make its prediction, and this is *precisely* the access that we must not give it! Even disclosing the *names* of my files to the hostile code must not occur. We need to think about this more -- there may be a reasonable compromise that is made possible with clever use of confinement (as there was for secure cut&paste). For now, I would say that the predictor function should simply be a list of regexps. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
