On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
<penguin-ker...@i-love.sakura.ne.jp> wrote:
>
> On 2019/03/28 4:16, Kees Cook wrote:
> > 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...)

> 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 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?

The situation you helped me see was that a TOMOYO user with
CONFIG_DEFAULT_SECURITY_TOMOYO would not want to see any exclusive LSM
also initialized, since that may NOT be a no-op.

So, AFAICT, my proposal fixes both Jakub's issue
(CONFIG_DEFAULT_SECURITY_* oldconfig entirely ignored) and Randy's
issue (subset of Jakub's: choosing DAC should mean no legacy major
initializes), and the "TOMOYO user surprised to see an exclusive LSM
also initialized". If you're happy with the proposed change in my
prior email, I'll send it properly to James. If not, what do you see
that needs changing?

Thanks!

-Kees


--
Kees Cook

Reply via email to