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]

Date:	Fri, 31 Aug 2012 15:49:00 -0700
From:	Eric Paris <eparis@...isplace.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	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

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.

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