Thank you for replying to this and my other email. It is good to learn
that the project is still active.
Post by Mark
Should I, for example, set them all to 1 (learning mode), save the
policy, reboot the system, and then after a while I can update the
policy to Enforce? Should I only set this domain to 1, or should I do
this for the children as well?
It depends on your concern and the purpose of using TOMOYO,
so there's no ready-made answer for the above question.
True words that I wanted to let sink in for a while, together with the
things I have read about Tomoyo so far. They made me realise that the
broad flexibility of Tomoyo, combined with various use cases one could
choose, seems to be a limiting factor in my case. I will explain what I
It is not hard for me to understand the hierarchical approach Tomoyo
has, expanding processes from <kernel> all the way down, splitting into
arbitrary domains when configured to do so. But if someone would ask me
right now if I can compare my experience with Tomoyo, I would tell them
to imagine as if today someone would hand me a ball of clay for the very
first time, and I had never learned what clay is and what you can do
with it. Then they tell me "you can do anything you want with this. Make
something beautiful," followed by them walking to a distance. I am sure
the look on my face would be limited to a blank gaze and an hour later
there would probably not be much more than how the ball looked when they
gave it to me. "Uhmm.."
The look I have had when thinking about how to apply Tomoyo is
pretty much the same I suppose. With one difference: this time no one
handed me Tomoyo, I searched for it. Or to put it more accurately, I got
curious when seeing the Tomoyo option in my kernel's menuconfig for the
n-th time. :)
Post by Mark
If you say unsure, why don't you start playing with daemons first?
Once you master how to limit/enforce daemons, you'll be able to
do the same for init scripts (if you want, of course).
To be practical, here is what happened when I wanted to start with the
postfix MTA process which has been spawned by an init.d process after
the system booted up.
I see that postfix executed one of its own scripts, and I see that that
process has executed, for example, /bin/cp. Thoughts going through my
head are, "I don't fully know what this process does, it seems to be
required by postfix and I assume that this script behaves in the same
way every time it is executed. Should I look at the script? Maybe, but
does that mean I have to do this with all scripts? That could take a
while. Should I let its children be in the same domain? Or should I put
that script and its children into postfix's domain? What if postfix is
restarted from a shell? Do I want to allow that or should I prevent that
fromhappening and force it so that postfix can only be started from the
init.d script? What if I block too much? What if it happens when I'm
stuck in traffic?" You get the idea, I'm sure.
This is when it starts to become a mind game. It's not Tomoyo's fault;
it's because of how my mind seems to deal with the learning curve. It's
an eager mind though and you can see how easily it diverges.
Post by Mark
Or, you can put everything (every process) under learning mode, and
then decide what to restrict.
(like TOMOYO Live CD
I am really not a fan of Ubuntu so I copied a Funtoo system that runs in
production to a testing machine. Okay, my earlier thought of being stuck
in traffic is a bit compulsive, that much is true. :) I assume this
Funtoo system allows for pretty much the same though.
As you can see, the idea of "everything is possible," while appealing,
is a bit overwhelming for my particular character.
Even though I have already let go of my desire to get everything up and
running in 10 minutes, so to speak, I would like to be taught about
which choices I can make so that I learn which choices make sense. In my
particular use case it's for a server running a collection of standard
Internet daemons like an MTA, a webserver and a DNS server.
I am looking forward to your thoughts.
Arigato gozaimasu :)