Re: 2.1.0-pre3 posted

Tikka, Sami wrote:
> README.trusted did not specify what happens when a trusted process dies
> without calling dazukoUnregisterTrusted(). Does the dazuko driver detect the
> death and remove the process from the list of trusted processes (this might
> be impossible)? Or is it up to the registered process(es) to monitor the
> trusted process(es) and tell dazuko to no longer trust it if it should die
> unexpectedly? This would work very well when the registered process is the
> parent of the trusted process. AFAIK the parent process is the only one who
> is notified when a process dies.

Hi,

In the current implementation, Dazuko does not handle the situation where 
the trusted process dies. This means that the trusted "pid" is still 
trusted. This is unsafe.

For the 2.1.0 this will be handled with 2 additional implementations.

1. A process will not only be identified by PID. Other things such as 
task_struct pointers and process attributes will also be used. This greatly 
reduces the risk of some other process "posing" as the trusted process.

2. If a process that looks similar to the trusted process (ie. has the same 
PID) tries to do something, Dazuko will automatically remove the trusted 
priveledge. This will prevent processes from trying to imitate a trusted 
process using brute force techniques.

These two additions didn't make it into the 2.0.1-pre3 version, because I 
wanted to get the API "out the door" so that you guys could try it out and 
give me some feedback.

However, these are just additions to help reduce the risk of an unwanted 
process getting trusted priveledges. But the safest action is still to have 
your trusted process "sign off".


> However, there is no API call to remove trust from one process, there is just
> dazukoRemoveAllTrusted()

Yes, a registered process can clear all trusted processes in this way. This 
API resembles the AddIncludePath and RemoveAllPaths logic.


> I think it would make sense to add a call like:
> int dazukoRemoveTrusted(pid_t trusted_pid)

This is problematic, because (as I mentioned at the beginning) a process 
will not be identified by PID alone. Although this could be used as a 
criteria for removing trust (removing trust doesn't have to be as secure as 
assigning it), but I don't like using PID's in Dazuko's API. It is too 
platform-specific.


> I would also like to be able to place trust on a process that is not
> dazuko-aware, but I can make them dazuko-aware if the API stays as it is.

As mentioned in the other thread with Calin Culianu, I don't think it is 
safe to trust applications that aren't Dazuko-aware. Providing such an API 
would be dangerous. I would only allow something like this if there was a 
secure OS framework already in place (such as RSBAC) so that the trusting 
can be enforced on another secure level.

Also mentioned in the other thread is an introduction of fine-grained access 
masks. These would only be group-specific, but may also be suitable for what 
you are trying to do.

But regardless of what is used, there is still the problem of removing 
individual settings/masks/trusted-apps. I am not sure how this could be done 
in a clean and flexible manner.

dazukoRemoveIncludePath() ?
dazukoRemoveExcludePath() ?
dazukoRemoveIncludeEvent() ?
dazukoRemoveExcludeEvent() ?
dazukoRemoveTrustedApplication(token) ?

John Ogness

-- 
Dazuko Maintainer