Re: [PATCH] security: unconditionally call Yama

[Eric W. Biederman]

Eric Paris <eparis@xxxxxxxxxxxxxx> writes:

> On Fri, Aug 31, 2012 at 2:39 PM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
>> On Fri, 31 Aug 2012 14:31:26 -0700
>> Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>>
>>> Unconditionally call Yama, no matter what LSM module is selected.
>
>> Not a good plan. What happens when everyone decides to stack every module
>> by ifdeffing in the kernel - mayhem. I'm all for it being possible but
>> done right - espeicall as I believe a proper proposal now for stacking
>> modules, and it should be done as part of that.
>
> I think a lot of us agree it's a 'difficult' plan going forward.  Kees
> wrote this patch after we (James, SELinux, AppArmor people) talked at
> the Security Summit earlier today.  From my PoV we have a couple of
> 'classes' of LSMs.
>
> Big with Labels: SELinux and SMACK
> Big without Labels: AppArmor and TOMOYO
> Small and stateless: Capabilities and Yama (and maybe integrity)
>
> Those small and stateless LSMs can easily stack.  We don't have object
> lifetime issues.  We don't have difficult technical details.  We all
> here seem to want to stack 'small and stateless' with 'big boy'.
> Outside one little capabilities and selinux setxattr issue I can't
> think of anything even quirky.  So the fast path forward, in my mind,
> is to start here with Yama.  Our choice *today* is adding these static
> hooks inside the 'big boy' LSMs (which I think all of us are willing
> to do) vs adding it one time in the LSM and not having to worry about
> it all over the place.  Getting the big guys and the little guys to
> play together is not going to lead to a mess of crazy.
>
> Stacking the big boys is a future goal most of us are happy with
> seeing done, if it turns out to be reasonable.  We know it's close to
> possible.  Dave Howell's gave us an implementation about 2 years ago.
> Casey Schaufler demo'd another stacking interface today.  No code from
> the latter, but the only limitation he really mentioned today was that
> two big guys with labels can't stack together.  I don't know how/if
> Dave's implementation wanted to handle that case.
>
> I really think this patch is good.
>
> Acked-by: Eric Paris <eparis@xxxxxxxxxx>
>
> I think I even want to do the same thing with capabilities so I don't
> have to make sure I'm getting those right in SELinux.  And everyone
> else probably doesn't want to keep those hooks themselves either.  I
> should send that patch to Linus.  I bet I can give him a large
> negative diff.  He did just say two days ago that he'll take any -1000
> line diff after -rc6   :)
>
> I think Casey and Dave need to both get their larger stacking
> solutions posted and we should go with the best one.  It'll let us
> pull out the static code, but for now, I like the static coding
> between the big boys and the little guys.  Lets fix today what's easy
> and fix tomorrow what we can't fix today.

>From a overal kernel maintenance and use perspective the unconditional
enablement is a pain.

We long ago established the principle that compiling additional code
into the kernel should not change the semenatics of the kernel.

So this code needs to come with a command line or sysctl on/off switch
not an unconditional enable.

Eric
--
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/