Discussion:
[tomoyo-users-en 557] Using Tomoyo with init scripts
(too old to reply)
Mark
2013-08-24 15:46:35 UTC
Permalink
Raw Message
Hi all,

I've been reading about, and playing with Tomoyo 2.5 on a Funtoo
hardened system that has kernel 3.2.50 with grsec. Funtoo is a Gentoo
derivative.

I have enabled a default policy with "emerge --config tomoyo-tools".
Then rebooted and now I see, for example, domains of the form:

<kernel> /etc/init.d/SCRIPTNAME

Obviously there are a lot of these so now my question is about the
learning policy (#1).

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?

I assume that this would create sane defaults that can be enforced if
the programs/daemons are called from the init scripts (which, on my
system, is how the programs should always start).

The documentation does name how to build policies for daemons, but with
the domains I mentioned I'm unsure about what is a good practice.
Comments appreciated, thank you :)

Mark
Toshiharu Harada
2013-08-27 06:22:55 UTC
Permalink
Raw Message
Hi, Mark,
Post by Mark
Hi all,
I've been reading about, and playing with Tomoyo 2.5 on a Funtoo
hardened system that has kernel 3.2.50 with grsec. Funtoo is a Gentoo
derivative.
I have enabled a default policy with "emerge --config tomoyo-tools".
<kernel> /etc/init.d/SCRIPTNAME
Obviously there are a lot of these so now my question is about the
learning policy (#1).
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.
Post by Mark
I assume that this would create sane defaults that can be enforced if
the programs/daemons are called from the init scripts (which, on my
system, is how the programs should always start).
From the viewpoint of TOMOYO (if it makes sense :-), there's no
concepts nor differences between daemons and init scripts.
Everything appears to be just a process.
Post by Mark
The documentation does name how to build policies for daemons, but with
the domains I mentioned I'm unsure about what is a good practice.
Comments appreciated, thank you :)
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).

Or, you can put everything (every process) under learning mode, and
then decide what to restrict.
(like TOMOYO Live CD
http://tomoyo.sourceforge.jp/1.8/ubuntu10.04-live.html.en)

Cheers,
Toshiharu Harada
haradats at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-users-en/attachments/20130827/27629bd1/attachment.htm
Mark
2013-09-01 23:25:08 UTC
Permalink
Raw Message
Hello Toshiharu-san,

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

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
http://tomoyo.sourceforge.jp/1.8/ubuntu10.04-live.html.en)
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 :)

Mark
Tetsuo Handa
2013-09-03 12:52:08 UTC
Permalink
Raw Message
Hello.
Post by Mark
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.
OK. You want to know when to do (or not to do) domain transitions, right?



Simple (and hopefully reasonable) approach for protection purpose will be

(a) apply initialize_domain directive to each init script and each daemon
program

and

(b) apply keep_domain directive to each init script

.

In this way, total number of domains will be kept small while applying
fine-grained restriction.

/usr/lib/tomoyo/init_policy tries to follow the approach listed above.
But since the database built into init_policy is outdated (this database was
made in the era of Red Hat Linux 9 and Debian 3.1, and desktop applications
were not taken into account), you would need to manually adjust keep_domain
entries and initialize_domain entries (especially for daemons and desktop
applications like web browsers).

For postfix as an example, you can specify

initialize_domain /path/to/init/script/for/postfix
keep_domain /path/to/init/script/for/postfix
initialize_domain /path/to/main/program/of/postfix

, and you can optionally specify

keep_domain /path/to/main/program/of/postfix

if you are not interested in splitting subprograms executed from main program.

You can use /usr/sbin/tomoyo-pstree to see whether daemon programs are running
in the domain you intended.



Well, TOMOYO is also an analysis tool. For those who want to study how Linux
systems work, all initialize_domain entries and keep_domain entries can be
removed. While I had no experience in administrating Linux systems, I improved
the skill of administrating Linux systems to the level of passing LPIC 303 exam
via developing and using TOMOYO. ;-)
Tetsuo Handa
2013-09-03 13:42:09 UTC
Permalink
Raw Message
Some corrections to the previous posting.
Post by Tetsuo Handa
Simple (and hopefully reasonable) approach for protection purpose will be
(a) apply initialize_domain directive to each init script and each daemon
program
and
(b) apply keep_domain directive to each init script
.
In this way, total number of domains will be kept small while applying
fine-grained restriction.
/usr/lib/tomoyo/init_policy tries to follow the approach listed above.
/usr/lib/tomoyo/init_policy tries to follow (a), but (b) is up to users
because default configuration tries to split domains as much as possible.



I forgot to add "from any" part of initialize_domain directive and "any from"
Post by Tetsuo Handa
For postfix as an example, you can specify
initialize_domain /path/to/init/script/for/postfix
initialize_domain /path/to/init/script/for/postfix from any
Post by Tetsuo Handa
keep_domain /path/to/init/script/for/postfix
keep_domain any from /path/to/init/script/for/postfix
Post by Tetsuo Handa
initialize_domain /path/to/main/program/of/postfix
initialize_domain /path/to/main/program/of/postfix from any
Post by Tetsuo Handa
, and you can optionally specify
keep_domain /path/to/main/program/of/postfix
keep_domain any from /path/to/main/program/of/postfix
Post by Tetsuo Handa
if you are not interested in splitting subprograms executed from main program.
Loading...