lkml.org 
[lkml]   [2012]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] security: unconditionally call Yama
Eric Paris <eparis@parisplace.org> writes:

> On Fri, Aug 31, 2012 at 2:39 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> On Fri, 31 Aug 2012 14:31:26 -0700
>> Kees Cook <keescook@chromium.org> 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@redhat.com>
>
> 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


\
 
 \ /
  Last update: 2012-09-01 03:01    [W:0.043 / U:1.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site