[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dazuko-devel] 2.0.6 released
From: |
Calin A. Culianu |
Subject: |
Re: [Dazuko-devel] 2.0.6 released |
Date: |
Tue, 22 Mar 2005 16:52:34 -0500 (EST) |
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
- [Dazuko-devel] 2.0.6 released, John Ogness, 2005/03/20
- Re: [Dazuko-devel] 2.0.6 released, Calin A. Culianu, 2005/03/21
- Re: [Dazuko-devel] 2.0.6 released, John Ogness, 2005/03/22
- Re: [Dazuko-devel] 2.0.6 released, Sami Tikka, 2005/03/23
- Re: [Dazuko-devel] 2.0.6 released, John Ogness, 2005/03/23
- Re: [Dazuko-devel] 2.0.6 released, Calin A. Culianu, 2005/03/27
- Re: [Dazuko-devel] 2.0.6 released, Calin A. Culianu, 2005/03/27
- Re: [Dazuko-devel] 2.0.6 released, Calin A. Culianu, 2005/03/27