linux-kernel - Re: [PATCH] security: unconditionally call Yama

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ipbyfw9j.fsf@xmission.com>
Date:	Fri, 31 Aug 2012 16:59:36 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Eric Paris <eparis@...isplace.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Kees Cook <keescook@...omium.org>,
	linux-kernel@...r.kernel.org,
	James Morris <james.l.morris@...cle.com>,
	Eric Paris <eparis@...hat.com>, Jiri Kosina <jkosina@...e.cz>,
	John Johansen <john.johansen@...onical.com>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH] security: unconditionally call Yama

Eric Paris <eparis@...isplace.org> writes:

> On Fri, Aug 31, 2012 at 2:39 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> On Fri, 31 Aug 2012 14:31:26 -0700
>> Kees Cook <keescook@...omium.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@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/