[Top][All Lists]
[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