Re: [Dazuko-devel] 2.0.6 released

[John Ogness]

Calin A. Culianu wrote:
> 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...

You need to be careful with this "poor man's solution". Especially if you 
only have one registered process, it is very easy to get caught in deadlock.

We will assume Process A is registered and Process B is not.

1. Process A receives an event and sends to Process B
2. Process B tries to do something with this event, which causes another 
event to be generated
3. <DEADLOCK>

Process B cannot continue until the new event it caused is accepted. But 
Process A cannot accept any new events until it gets feedback from Proccess 
B (for the first event).

The Trusted Application Framework solves this problem because Process B will 
no longer cause events to be generated.

Of course, if you have a bunch of registered processes in the same group 
(which you probably do), than any of the other processes could respond 
directly to Process B's event and everything continues ok. But this 
generates twice as many context switches.


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

Yes, this is correct. This problem stood on the Dazuko TODO list for nearly 
two years. But in 2.1.0 it is finally being handled.


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

Yup.


> 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)?

Lock Dazuko? So no one else can register? No, this is not possible. Should 
this be a feature for the TODO list? Using Dazuko with RSBAC allows 
something like this. With RSBAC you must "mark" the binaries that are 
allowed to interact with Dazuko.


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

2.1.0-pre3, which should be posted any day now (as soon as I actually find 
some free time), runs very stable. It is much faster, has many new features, 
produces more reliable events for Linux 2.2/2.4 and FreeBSD 4/5, and fixes a 
lot of longstanding known problems with previous versions.


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

dazuko-devel is a good place for this discussion. Most of the topics you are 
asking about have never really been discussed in depth before.

John Ogness

--
Dazuko Maintainer