3.2-rc1 rebase review

[Kees Cook]

On Wed, Nov 9, 2011 at 5:50 AM, Tetsuo Handa
<from-ubuntu at i-love.sakura.ne.jp> wrote:
> Kees Cook wrote:
>> > UBUNTU: ubuntu: Yama - unconditionally chain to Yama LSM
>>
>> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commitdiff;h=336823e68877aeaea2b3ec680671612e10770616
>>
>> Looks correct to me. And any runs of the qrt test-kernel-hardening.py
>> regression test will catch it if it's not operating correctly.
>
> Please use
>
>  +#ifdef CONFIG_SECURITY_YAMA
>
> rather than
>
>  +#if CONFIG_SECURITY_YAMA

I'll make these updates, thanks.

> BTW, if Yama is unconditionally chained as long as CONFIG_SECURITY_YAMA=y,
> why do we want
>
>  +       if (!security_module_enable(&yama_ops))
>  +               return 0;
>  +
>  +       if (register_security(&yama_ops))
>  +               panic("Yama: kernel registration failed.\n");
>
> at yama_init()?

My intention is to allow someone to boot an Ubuntu kernel with
"security=yama" and not have things go weird. This is, of course,
predicated on the idea that Yama will be upstream. I felt that these
changes for the stacking allowed the least surprise for the user.
(Yama is always in the stack, and you can still select it directly.)

> because passing security=yama causes default capability hooks (which are no-op)
> to be called after yama hooks are called.

I'm not entirely following you. With the Yama forced stacking patch,
Yama's hooks are always run first, and if another LSM is primary, then
its hooks are run if Yama didn't reject it. The results should be the
same whether booted with "security=yama" or not. Maybe I've
misunderstood something?

-Kees

-- 
Kees Cook
ChromeOS Security