Re: 2.0.6 released

On Tue, 22 Mar 2005, John Ogness wrote:

>
> 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.
>

Ah of course.. otherwise Dazuko would just ignore all capabilities and 
upset those people that want to use them (I personally never have but I 
know some people who love them).

>
> The upcoming Trusted Application Framework may also help you here.

Yeah, although for now the poor man's solution (which is what I did) is 
just to do the work yourself in your application of determining who 
you trust, etc based on things like executable name or process group 
id, etc.  It's slower though, definitely, as you have all that context 
switch overhead.. but for anyone that needs it working now, it is 
better than nothing...

>
> 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.

Ah.. I see.  Of course... this is indeed a very good feature.

>
> 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.
>

So include/exclude paths and access mask are global to the system?

Hmm so in 2.0.6 if "GroupA" listens on / with exclude of /proc and 
"GroupB" listens on / with exclude of /dev and /sys, in actuality the 
union of the two exclude sets (/proc, /sys, /dev) is used as an exclude 
for both groups?  So neither will get events from that exlcude set?

What happens with access mask? Does the latest one clobber previous ones 
set by other Groups?

Hmm that's good to know.  In my app I probably won't be using more than 
one group and I am assuming the system has no other apps using dazuko.. 
but.. is there any way to lock dazuko in 2.0.6 (I could just grok the 
sources to find out)?  If not don't worry about it (not that I imply you 
should) as I look forward to usiung 2.1.0 as soon as I get around to 
seeing how stable it is.. (still playing around with my actual app before 
I can work on such optimization steps).

(If you would rather I search the mailing list archives to answer my 
numerous questions I can but it's fun to talk to you about this..)

> 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.

Ah, of course.  So the kernel 1. doesn't wait for userspace but just 
rather goes on its merry way asynchronously and 2. usermode deosn't have 
to context switch back kernel mode to give an answer.  Ah I get it!

Thanks for your help and your most useful and cool software!!

Cheers,

-Calin