Re: TOMOYO Linux Security Goal

[Tetsuo Handa]

Hello.

Valdis.Kletnieks@xxxxxx wrote:
> Please make a *big* notation someplace that "learning mode" is quite likely to
> *not* produce a totally correct policy.  In particular, it won't build rules for
> infrequently used code paths (such as error handling) unless you find a way to
> exercise those paths while in learning mode.
Use of "learning mode" is independent from "correct policy".
The "learning mode" merely takes your duty of appending permissions to policy.
We can develop and share procedures for how to exercise infrequently used code
paths, like how to confirm that your SMTP service won't relay spams.
This problem is nothing but "developing and sharing procedures for how to
exercise infrequently used code paths" has not started yet.

By the way, what is the definition of "correct policy"?
The definition of "correct policy" depends on the user.

Some users may think that

  "A ready-made policy is better than a manually-made policy
   even if the ready-made policy contains unused/unneeded permissions.
   Being unable to handle infrequently used code paths is worse than
   leaving a room for not knowing/understanding what can happen."

but other users may think that

  "A manually-made policy is better than a ready-made policy
   even if the manually-made policy lacks permissions for infrequently
   used code paths.
   Leaving a room for not knowing/understanding what can happen is worse than
   being unable to handle infrequently used code paths."

You can use "permissive mode" to adjust and confirm your policy
before you use "enforcing mode".
You can also use "delayed enforcing mode" that allows an administrator
handle infrequently used code paths without once rejecting those code paths.
If the policy is not correct, it is the person's fault who enforced that policy
without confirming that that policy is suitable for his/her system.

Since the definition of "correct policy" is not a globally agreed word,
I think we can't say that "learning mode unlikely produces correct policy".

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/