Message-ID: <555780C3.7040303@schaufler-ca.com>
Date:	Sat, 16 May 2015 10:39:15 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	jmorris@...ei.org
CC:	james.l.morris@...cle.com, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, pmoore@...hat.com,
	john.johansen@...onical.com, sds@...ho.nsa.gov, eparis@...hat.com,
	keescook@...omium.org, Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PULL] LSM: Basic module stacking infrastructure for security-next-
 Acked

On 5/15/2015 5:56 AM, Tetsuo Handa wrote:
> 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@...hub.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.

That is correct. It's the reason that the changes are reasonable.
Yama was the case that tipped the barrel. It was clear that a number
of distros wanted Yama, and that the security modules they already used
couldn't really incorporate the Yama changes. Hence stacking. The
special purpose Yama stacking was sufficient to demonstrate that a more
general mechanism was in order. Because Yama doesn't use security blobs
the general stacking didn't have to address the "void *security" issue
to be useful.

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

Although I agree with you that it makes more sense to hang task data
off of the task structure than off of the cred structure I don't like
the notion of having both. I wasn't heavily involved in the cred split
(and was not then and not now a fan of it) and missed the discussion
about why the security blob is included in the cred. But, that's where
it ended up. I would have no objection to moving the blob from the cred
to the task, although I expect there are reasons for it to remain
where it is.

For now at least, I propose that we leave the security blob in the cred.
I will be proposing mechanisms for dealing with that pesky "void *security"
shortly. During the time I've been working on stacking I've identified
a veritable plethora of ways to address the issue. I am putting together
a menu of options and a set of arguments to help guide an open debate on
which suits the current state and direction of the kernel best.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

Powered by blists - more mailing lists