To: casey@schaufler-ca.com, jmorris@namei.org
Cc: james.l.morris@oracle.com, linux-security-module@vger.kernel.org,
        linux-kernel@vger.kernel.org, pmoore@redhat.com,
        john.johansen@canonical.com, sds@tycho.nsa.gov, eparis@redhat.com,
        keescook@chromium.org
Subject: Re: [PULL] LSM: Basic module stacking infrastructure for security-next- Acked
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
References: <55454539.9020204@schaufler-ca.com>
	<554D6BCD.7090009@schaufler-ca.com>
	<alpine.LRH.2.11.1505121501350.30679@namei.org>
	<5552D0ED.703@schaufler-ca.com>
In-Reply-To: <5552D0ED.703@schaufler-ca.com>
Message-Id: <201505152156.ICG18254.HFMOVJOOFLFStQ@I-love.SAKURA.ne.jp>
Date: Fri, 15 May 2015 21:56:16 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4772
Lines: 99

Casey Schaufler wrote:
> On 5/11/2015 10:02 PM, James Morris wrote:
> > On Fri, 8 May 2015, Casey Schaufler wrote:
> >
> >> James, here's an updated pull request for LSM stacking.
> >> Acks have been applied.
> >>
> >> The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
> >>
> >>   Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>   git@github.com:cschaufler/smack-next.git stacking-v22-acked
> > fyi, this is not a public URN.
> 
> https://github.com/cschaufler/smack-next.git should work.
> 
> >
> >> for you to fetch changes up to f17cd945a8761544ac9bfdaf55e952e558dbee3e:
> > Applied to
> > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next
> >
> Thank you. I'm glad I was able to address all of the feedback from the
> earlier versions. Special thanks to Tetsuo, who really kept me honest,
> and Kees, who kept encouraging me to try again.

Congratulations! You achieved a great step.

Casey Schaufler wrote:
> On 5/12/2015 2:17 AM, Lukasz Pawelczyk wrote:
> > I have 2 questions regarding those patches:
> >
> > 1. Will it be possible to stack arbitrary LSMs with it? Cause right now
> > the only thing I see that is actually being used is Yama that is
> > configured on the init level instead per LSM hook. I don't see any means
> > to select any LSM module I want with this (yet?)
> 
> No. The behavior is the same as before, but with a different framework.
> Where before there were two special case modules (capability and Yama)
> there is now a general scheme that is only slightly utilized. "Yet" is
> in fact the key word. There are security blob and secid issues that this
> set does not address. That's the next round.

But it will become easier to load single function LSM modules which do not
conflict with security blob and secid limitations.

> 
> > 2. What about "void *security" pointers in various system objects (task,
> > inode, file, etc). If you would stack e.g. Smack and SELinux together
> > right now they would conflict. Are there plans to handle this as well?
> 
> That's the plan. The community felt that it was better to address the
> generalization of capabilities and Yama stacking before tackling that
> issue. And, of course, it's generally believed that Smack+Tomoyo or
> SELinux+AppArmor is much more interesting than SELinux+Smack. Frankly,
> I've never wanted to see a security admin's head explode, and I fear
> that it could happen in the SELinux+Smack case.
> 
> My intention is to encourage smaller, targeted security modules. You
> are very limited in what you can do today, with the blob pointers the
> way they are. I will be making some proposals in the arena once I've
> caught up on some of the other tasks on my plate.

I would like to propose revival of security_task_alloc()/security_task_free()
hooks. I have several single function modules which want to use these hooks.

4 years ago, I wrote
http://osdn.jp/projects/akari/scm/svn/blobs/head/branches/uuid4.c
which is targeted for restricting qemu processes managed via libvirtd process
with operations in case bugs like VENOM: QEMU vulnerability (CVE-2015-3456)
are discovered, without making system administrators' heads explode by
enforcing SELinux. When isolating processes, use of per "struct task_struct"
blob saves a lot of unnecessary duplication of per "struct cred" blob.

Another module which want to use security_task_alloc()/security_task_free()
is kportreserve, which does not need to distinguish users but wants to cache
current thread's executable path. In general, my LSM modules try to distinguish
not users but processes. Therefore, per "struct task_struct" blob is convenient
for me.

I could not afford proposing this kind of single function modules for mainline
at that time. But now, if we wish to accept this kind of modules, I can update
them and propose for mainline. (If we wish to keep this kind of modules away in
order to avoid getting security/ directory bloated, I'm OK with only exporting
security_hook_heads; I'll continue managing as out-of-tree LSM kernel modules.)

If security_task_alloc()/security_task_free() come back (and optionally
"void *security" in "struct task_struct" also comes back), we can run
{SELinux,Smack,AppArmor}+TOMOYO now, for what TOMOYO is designed to use as
security blob is "struct task_struct"->security than "struct cred"->security.

Can I again propose security_task_alloc()/security_task_free() hooks for
these single function modules and TOMOYO?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/