Re: 2.0.6 released

Calin A. Culianu wrote:
> Does Dazuko use capabilities in order to intercept file access events?

No. But in order to allow the capability module to stack on top of 
Dazuko, Dazuko must correctly hook all LSM capability functions. Dazuko 
itself does not use these functions.


> Yes.. it's possible that my application was entering a deadlock 
> situation. It actually did really crazy things like interact with 
> another daemon process via a unix socket.  That process was also 
> generating dazuko events, and I suspect in some situations if my thread 
> pool limit is reached then basically everyone is waiting for a new 
> dazuko access to get picked up, but it never comes since my threads are 
> maxed out... or something like that.  Anyway I reworked it so that the 
> daemon process doesn't generate dazuko events.

The upcoming Trusted Application Framework may also help you here.


> I am doing this, but I actually am unclear on the effect the groupname 
> has.  Suppose I have a bunch of threads monitoring the same directories, 
> and they are all with the same groupname.  Now suppose you have another 
> group doing the same thing on a different set of directories, but those 
> all have different groupnames from each other (naive programmer set the 
> groupname to be the threadid of the thread or something).  How will the 
> two situations differ?

Dazuko assumes that processes under the same groupname are working 
together. This means that if an access event occurs, it will send the 
information to ONE of the processes in the group.

If there are more than one group, than Dazuko will send the access event 
to ONE process from EACH group.

Groups were added to Dazuko so that multiple programs could all use 
Dazuko at the same time. For example, an anti-virus scanner will 
register under one group name and do file-access control for /home. 
Whereas a system activity logger from another organization will register 
as read_only and watch /. Since the two applications use different group 
names, they will be handled separately.

In 2.0.6 all groups share the same include/exclude paths and access 
mask. But in the 2.1.0 version, each group has their own settings.


> It's actually read/write (it can deny access).  I didn't know that 
> read-only is faster and saves context switches!!  I'll keep it in mind 
> for my future Evil needs.  Thanks very much for your advice!!  :)

Read-only has less context switches because the "answer" doesn't need to 
be sent back to the kernel. In read-only mode, dazukoReturnAccess() 
doesn't actually send anything back to the kernel.

John Ogness

-- 
Dazuko Maintainer