Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751673AbbEPRjP (ORCPT ); Sat, 16 May 2015 13:39:15 -0400 Received: from smtp106.biz.mail.bf1.yahoo.com ([98.139.244.54]:25866 "EHLO smtp106.biz.mail.bf1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751039AbbEPRjK (ORCPT ); Sat, 16 May 2015 13:39:10 -0400 X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: D9JQ0L4VM1kHgDiC_VWB4EU8YrclIOpajOG8IgBDn35cAd7 fbROkgzNZxitxj3fankSHDTyroZCTxP5pCNnxiG9yv3CDJzdmOUbkvZyylkd eQ2bWgxafK6xUdS1iQQl0961x6vx7z4XaQrAXPM74Zaqw_avKLgIrBqzV.xk mcwF3sO9Vzgm6Koa2gpC4G_0lc3bNxPHuUgN_DNOSCIbL0q7UqJe4ag_c8Tm PZFweDnJuqxKY9BoWt7rLNB0rBv.TBWBzQdo6Th4BG.bqdhKgTbezRLbQH0z s72_O4GnNXLaFOKZY0pfOFzy4nrdJSTPRSwgFA23yfA0FH9j9vI8T9C30bmk APjZXW1KdgTO.T_zE.Lj0L4xaa3mx6A2lpAnjsGTYDqSWkWZ0cOy505Fza1R .7reO5DJosjf.09g0ZpI6T5mk_lA0x3VWpFzQ56GGALKRXbipXDu1L1gXpeJ ko4HJJzVSxcxdVmcFsMBut8qmqWoqjuKQAQUEDbvX6LzP14bvLnw_vJ9c6rK JsWRI8B5emDnTnCi50aEGAN96ru.sl2EZ0w-- X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Message-ID: <555780C3.7040303@schaufler-ca.com> Date: Sat, 16 May 2015 10:39:15 -0700 From: Casey Schaufler User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tetsuo Handa , 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, Casey Schaufler Subject: Re: [PULL] LSM: Basic module stacking infrastructure for security-next- Acked References: <55454539.9020204@schaufler-ca.com> <554D6BCD.7090009@schaufler-ca.com> <5552D0ED.703@schaufler-ca.com> <201505152156.ICG18254.HFMOVJOOFLFStQ@I-love.SAKURA.ne.jp> In-Reply-To: <201505152156.ICG18254.HFMOVJOOFLFStQ@I-love.SAKURA.ne.jp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6535 Lines: 124 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@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. 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@vger.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/