On 2019/03/28 5:45, Kees Cook wrote:

On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
[off-list ref] wrote:

quoted

On 2019/03/28 4:16, Kees Cook wrote:

quoted

The part I don't understand is what you've said about TOMOYO being
primary and not wanting the others stackable? That kind of goes
against the point, but I'm happy to do that if you want it that way.

Automatically enabling multiple legacy major LSMs might result in a confusion like
Jakub encountered.

The confusion wasn't multiple enabled: it was a change of what was
enabled (due to ignoring the old config). (My very first suggested
patch fixed this...)

Someone else might get confused when TOMOYO is automatically enabled
despite they did not specify TOMOYO in lsm= or security= or CONFIG_LSM.

quoted

For a few releases from 5.1 (about one year or so?), since
CONFIG_DEFAULT_SECURITY_* will be ignored after CONFIG_LSM is once defined in
their kernel configs, I guess that it is better not to enable TOMOYO automatically
until most people complete migrating from CONFIG_DEFAULT_SECURITY_* to CONFIG_LSM
and get used to use lsm= kernel command line option rather than security= kernel
command line option.

It sounds like you want TOMOYO to stay an exclusive LSM? Should we
revert a5e2fe7ede12 ("TOMOYO: Update LSM flags to no longer be
exclusive") instead? (I'm against this idea, but defer to you. I think
it should stay stackable since the goal is to entirely remove the
concept of exclusive LSMs.)

I never want to revert a5e2fe7ede12. For transition period, I just don't
want to automatically enable TOMOYO when people did not specify TOMOYO.

I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
also initializing TOMOYO, though. It should be a no-op. Is there some
situation where this is not true?

There should be no problem except some TOMOYO messages are printed.