Re: 2.1.0-pre3 posted
John Ogness <[email protected]>
| Newsgroups | gmane.linux.dazuko.devel |
|---|---|
| Message-ID | <[email protected]> |
Sami Tikka wrote: > My attitude comes from frustration: all suggestions I have made > regarding dazuko have been turned down by you. Perhaps we just see > things very differently. I know I was probably the first to request the > trusted application framework and obviously I am trying to guide the > development of TAF to a direction that would minimize re-work I have to do. Yes, this is the main point where we are disagreeing. You are trying to minimize your work, whereas I am trying to make things as secure and flexible as possible (even if it means extra work for the developers). > Here is my suggestion, with 2 points: > > 1) An application could ask to be trusted and the trust extended to its > child processes. The extension of trust to child processes would be > optional: > > int dazukoRegisterTrusted(const char *groupName, const char *token, int > trust_children); What is meant by child processes - threads, forks, both? If a thread registers with trust_children=1, does Dazuko trust the parent also? When a trusted process does a fork-exec, do I trust this new process as well? I like the idea of providing an option to trust "related processes", but I am concerned about the overhead. It would mean that when an access event occurs, Dazuko must search through all trusted processes and check if somehow this process is "related" to one of them. This might be expensive. Expensive is ok if it is justified. It is much cheaper if Dazuko knows ahead of time who can be trusted and who not. > 2) If the dazuko driver detects when a process has died and some other > unrelated process is running using the PID of a trusted process, I could > just ignore the handling of crashed scanner processes. I.e. a process > would remain trusted until the process itself asks not to be trusted > anymore or it has died. > > I don't think this is unsafe and anyway it is up to the registered > application to decide if it wants to accept the trust request and extend it. Yes, this is already how it will be implemented. A trusted process is not *required* to sign-off before exiting. It is just safer to sign-off because you don't have to rely on Dazuko's emergency fallback. But the fallback will be there nonetheless. > You probably do not like this suggestion because it uses the concept of > process. I don't mind the idea of processes (or processing entities). I *do* have a problem with PID's. If you can answer my questions about what "trust_children" means, then I think we can add this as an extra option. John Ogness -- Dazuko Maintainer