dazuko-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dazuko-devel] Comments on TAF


From: John Ogness
Subject: Re: [Dazuko-devel] Comments on TAF
Date: Sun, 27 Mar 2005 23:38:08 +0200
User-agent: Mozilla Thunderbird 1.0 (X11/20050313)

Calin A. Culianu wrote:
I have a question: so once an app is trusted, is that attribute basically limited to that particular process?

Yes. It is limited to the process that requested trusted access.


Is this by pid?

At the moment yes. I plan to make the "process-recognition" more fine grained in a later release. PID alone is not very trusting.


What happens after an exec call?

exec() is not a trusted event. When a registered process calls exec(), it causes this event to be generated. However, this causes re-entrance in the kernel, which is basically the same problem that TAF tries to solve. I don't want exec() to be a trusted event, but perhaps when a registered process calls exec(), the event should be generated for all groups EXCEPT the group of the process calling exec().


What if the app is multi-threaded (with cases such as: more than one PID on linux, or just one pid on say FreeBSD)?

Like I said, at the moment everything is PID based. For TAF this is not 100% reliable under Linux and does not work correctly under FreeBSD. A future release will do more fine-grained process identification.


I like the TAF, but do you think it could be modified to be easier to use with apps that aren't aware of dazuko?

Ie: it would be nice to make apps that have no concept of dazuko be trusted. Apps you didn't write and don't have the sourcecode to.

Hmmm. Trusting an application that you didn't write? Can such an application really be trusted? Having trusted access is an enormous priviledge.


This idea could be inverted a different way: perhaps it could be possible to give dazuko a finer-grained idea of what apps you are interested in getting events from, rather than just includes/exclude paths (which of course are a fundamental criterion!).

I like this idea much more. With a function like dazukoAddExcludeProcess(), where a registered process specifies processes that it doesn't want to know about. This would be specific to the registered group, the process would only be invisible to your group (but not to everyone else). I like this better because it gives you the option to ignore processes. Ignoring is different than trusting.

But perhaps the whole concept of dazukoAddExcludePath() should be generalized. Rather than specifying paths, you could specify any component of dazuko_access. For example, if there was a way that you could say:

"exclude close events in /usr/local/ from pid 1424, uid 233"

This would be much more powerful for allowing whatever kind of "ignoring" you wanted.

What about something like:

dazukoAddExcludeEvent(struct dazuko_access *);

Here an actual event is specified that should be used as an exclude mask. You could specify just a path, in which case it is identical to dazukoAddExcludePath(), or you could specify many attributes that are combined to create a mask.

These are just ideas for the moment. I need to think about this a bit.

John Ogness

--
Dazuko Maintainer




reply via email to

[Prev in Thread] Current Thread [Next in Thread]