[tomoyo-users-en 422] Re: TOMOYO Policy simplification

Back to archive index
Milton Yates milto****@loule*****
Thu Nov 24 06:41:25 JST 2011

Le 23/11/2011 04:59, Tetsuo Handa a écrit :
> TOMOYO has been trying to avoid inheritance of access permissions as much as
> possible.

I understand that as a very good initial requirement for a
straightforward and explicit auditing tool.
For access control, inheritance does not necessarily mean redundancy.
For me it is the other way around.
I agree with Jamie here that the policy writer has a big responsibility
to avoid creating redundancy. Unfortunately that is probably true for
all frameworks.

> Currently, TOMOYO kernel holds only one use_group line for each domain.
> This is something like allowing only one "#include" line in source code.
> Your suggestion is something like allowing multiple "#include" lines.

A good comparison

> Of course, it is technically possible to implement your suggestion in
> the kernel. The questions would be
>   (1) whether it is worth to implement your suggestion in the kernel

I think only you guys will make that decision :)

>   (2) inheriting multiple "use_group" lines to domains automatically
>       upon execve() might cause a lot of (unused) redundant permissions

I might miss your point here, please make it clearer if my view below
does not address your question.

If I can write something like:

<kernel> /bin/prog
use_profile 3
use_group BASE
use_group X
use_group GNOME
use_group IBUS
use_group PULSEAUDIO
file write /xxxx
<custom domain specific rules>

it is fairly easy to see what functions the application uses and what
has been authorized, compared to the same policy with all the explicit

<kernel> /bin/prog
use_profile 3
use_group 1
file read @X-HOME-RO
file read/write/truncate @X-HOME-RW
file read @X-FILES
file read @GNOME-RO
file chmod @IBUS-HOME 0700
file read @IBUS-HOME
file read /dev/shm/pulse-shm-\*
file create /dev/shm/pulse-shm-\* 0400
file read @PULSE-RO
file read/write/truncate/unlink @PULSE-RW
file write /xxxx
<custom domain specific rules>

As you can see, here I have already tried to group paths (FYI @GNOME-RO
is ~50 wildcarded paths). But because I can't group rules, I need to
create multiple group paths, usually one for read-only, one for
read/write "types". That is just some trick I used to simplify my
policies, but in reality having grouped rules would be much clearer and
Because using these group paths, I sometimes give more access than is
necessary (redundancy), that is a sacrifice I make in the hope that one
day I will still be able to read my policies, ie: when software updates
You may think this path grouping is probably worse than putting all
rules for the domain in one go, but how can you be sure no rule is
redundant when you have 150+ lines for one domain?

I think a good access control policy is something you need to be able to
read *again* :) Otherwise I would be using SELinux haha ;)

Grouping by functionality is also a good design principle in my view, as
it makes domain specific rules stand out. It is then easier to identify
abnormal requests from programs and avoid adding those rules. You
probably wouldn't spot those at first if it was in the middle of 150+
rules that you got from learning mode.

For me TOMOYO is good because it is simple, straightforward and
effective. I hope we can use multiple named grouped rules for policies
without cluttering the framework.

If you don't have time, I could start diving in the code to provide a
patch for this (in a few weeks). Although I am missing kernel coding
experience, I'm up for challenges - and would love to see this
functionality come alive.
I personally believe this would speed up policy writing for TOMOYO, once
the base groups have been defined.

Milton Yates

More information about the tomoyo-users-en mailing list
Back to archive index