Jamie Nguyen wrote:
> I testing ccs-patch and ccs-tools from revision 5106.

Thank you for testing.



> Things I noticed:
> 
> 1) After a fresh initialization of policy, I have all domains set to
> profile=0 but <kernel> domain keeps having "transition_failed". I
> can't quite figure out why this is appearing.

When a domain is marked as "transition_failed" (please see
http://tomoyo.sourceforge.jp/1.8/policy-specification/domain-policy-syntax.html.en#transition_failed
for meaning, and at the bottom of ccs_find_next_domain() in
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/security/ccsecurity/domain.c#L695
for implementation), TOMOYO will print the

  ERROR: Domain '%s' not defined.

line. Can you find the domainname from dmesg command's output?



> 2) The profile editor screen doesn't work as expected when doing
> "ccs-editpolicy /etc/ccs". Pressing "s" to edit for example the
> "3-PREFERENCE" line to have "enforcing_penalty=5" results in two lines
> that start with "3-PREFERENCE", instead of replacing the line that is
> being edited.

That is due to lazy implementation in order to absorb differences in the parser
used by the TOMOYO 1.8.x kernels. Keywords may be added within TOMOYO 1.8.x but
the userspace tools should not ignore the line even if it does not know how to
parse the line. Thus, offline mode is almost doing only "echo $line >> $file"
for addition and "grep -vF $line $file" for deletion because invalid lines will
be ignored and old values will be overwritten when parsed by the kernel.

But in order to save lines when embedding policy into the kernel, offline mode
should start using parsers which the kernel uses.



> 3) After creating a new profile line as in point (2), viewing
> profile.conf in a text editor reveals that the line we just added has
> the <kernel> prefix, whereas other lines for <kernel> namespace do not
> have this prefix. It should probably only have <kernel> prefix if
> other entries already have <kernel> prefix.

This output will change when offline mode started using parsers which the
kernel uses.



> 4) There is a way to create a new namespace, but no way to delete an
> existing namespace within ccs-editpolicy.

Namespaces are not automatically created whereas domains in a namespace are
automatically created. Therefore,

> It currently requires
> manually deleting entries from exception/domain/profile policy files.

we unlikely need to delete namespaces because we won't create namespaces
without reasons, as with we won't define profiles without reasons.

Thus, the kernel does not support deleting namespaces as well as the kernel
does not support deleting profiles. Same applies to the online editor.

> If that is actually what you intended then I can just add a paragraph
> to chapter-15.html.en about how to delete (using a text editor) a
> namespace that has been added.

Maybe the offline editor should support deleting namespaces. But since adding
namespaces using awk scripts is easy, deleting namespaces using awk scripts
will be easy.



> 5) I added "reset_domain /usr/bin/firefox from any" to exception
> policy. When the domain or profile is not yet defined, the error
> message described on chapter-15.html.en looks like this:
> 
> ERROR: Domain '</usr/sbin/httpd>' not ready.

Yes. But recent distributions tend to suppress kernel messages by adding
"quiet" option upon boot or changing /proc/sys/kernel/printk settings.
In that case, the

  ERROR: Domain '</usr/bin/firefox>' not ready.

line will not be printed on the console.
The line should be found from dmesg command's output or /var/log/messages .

> Should tomoyo be intercepting this execution and providing an error
> message similar to the one in chapter-15.html.en?

Please check dmesg or syslog, and you will find the error message.



> But when I run firefox from console, I instead got something that
> looks like this:
> 
> bash: /usr/bin/firefox: Cannot allocate memory

This is because TOMOYO returns ENOMEM after printing the

  ERROR: Domain '</usr/bin/firefox>' not ready.

line when the domain in a different namespaces or the profile for the domain is
not defined. Likewise, TOMOYO returns ENOMEM without printing the

  ERROR: Domain '%s' not defined.

line when the domain in the same namespace is not defined.

Since the former condition is always the user's error that the user has
forgotten to define domains after creating namespaces, TOMOYO always prints the
line. But since the latter condition can be due to TOMOYO's characteristic that
TOMOYO is trying to create domains in enforcing mode, TOMOYO does not print the
line in order to avoid log flooding.

If you like to see the

  ERROR: Domain '%s' not defined.

line in enforcing mode, we have several choices.

(1) Change the condition for marking domain as "transition_failed" from
    "program execution continued without domain transition within the same
    namespace because the mode was not enforcing" to "domain transition within
    the same namespace has failed; the program execution was rejected if the
    mode was enforcing, was continued without domain transition otherwise".

(2) Change the condition for marking domain as "transition_failed" from
    "program execution continued without domain transition within the same
    namespace because the mode was not enforcing" to "domain transition has
    failed; the program execution was rejected if the mode was enforcing or the
    domain was not within the same namespace, was continued without domain
    transition otherwise." and unify

      ERROR: Domain '%s' not ready.

    (currently used as an error message for indicating domain transition to
    different namespace has failed) and

      ERROR: Domain '%s' not defined.

    (currently used as an error message for indicating domain transition within
    the same namespace has failed).

(3) Always print

      ERROR: Domain '%s' not defined.

    line. (Would be noisy if flooded. To be quiet, currently this line is
    printed for only once if the mode is not enforcing and is never printed if
    the mode is enforcing.)

_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en

Reply via email to