Milton Yates wrote:
> Or did I miss once again something in the documentation ? :)
Nothing. ;-)
> The best I could find is to create path_groups in exception policy, then
> add these grouped Paths to grant permissions in the different domain
> policies. But this only groups Paths! I would like to be able to group
> {file read file1, file write file2}, not just file1 and file2 in the
> same path_group.
>
> I can do that by using the "use_group N" (acl_group) directive in domain
> policy,
Yes, acl_group was introduced for grouping {file read file1, file write file2}.
> but then I can only use ONE group for each domain :(
So far, the only way to emulate MULTIPLE groups is to use N as a bitmasked
value like
acl_group 1 file read file1
acl_group 2 file write file2
acl_group 3 file read file1
acl_group 3 file write file2
acl_group 4 file execute program1
acl_group 5 file read file1
acl_group 5 file execute program1
acl_group 6 file write file2
acl_group 6 file execute program1
acl_group 7 file read file1
acl_group 7 file write file2
acl_group 7 file execute program1
.
TOMOYO has been trying to avoid inheritance of access permissions as much as
possible. When this project started in April 2003, it was a tool that audits
access requests. Three characteristic points of this tool were
(1) groups access requests by the history of processes
(2) allows starting from scratch by automatically allocating history of
processes
(3) uses pathnames for recording access requests and history of processes
. By the end of 2003, this tool obtained ability to restrict access requests
based on white lists built from scratch. Thus, the characteristic point as an
access restricting tool is that the policy has no redundant permissions because
the policy is customly developed from scratch by appending permissions required
by applications.
As time went by and TOMOYO is getting used, users started asking for ready-made
policies (rather than customly developed from scratch).
Since I wanted to reduce redundant permissions in the policy, at first I
allowed only "file read" operation using "allow_read" directive because I
considered that reading shared libraries and locale data are acceptable
redundancy.
Then, I also allowed "misc env" operation using "allow_env" directive because I
considered that passing commonly used environment variables is acceptable
redundancy.
Then, I replaced "allow_read" directive and "allow_env" directive with
"acl_group" directive because I considered that "file write /dev/null" is
acceptable redundancy.
This is as of TOMOYO 1.8/2.4/2.5, and here comes your suggestion.
> As I have been writing policies for Tomoyo 2.4, I have searched for any
> way available to factor and simplify Tomoyo policies to make them as
> generic and reusable as possible.
> Most of the policies I write, currently for desktop applications, have
> common sets of rules based on the services of the system they use: dbus,
> X, gnome, alsa, pulse, etc.
> So it is desirable to have reusable policies, and not just copy/paste
> lines which is not efficient nor easy to maintain.
>
> I find this currently difficult to implement completely with Tomoyo.
>
> The best thing would be if we could name these policy groups (but
> numbers could do at first) and more importantly be able to assign *more
> than one group* to each domain.
> That would be great and would simplify existing policies by being able
> to group policies and make them easier to create/read/change/recertify,
> by making policies closer to a kind of role based approach.
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.
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
(2) inheriting multiple "use_group" lines to domains automatically created
upon execve() might cause a lot of (unused) redundant permissions
.
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
