From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752220AbdDJT00 (ORCPT ); Mon, 10 Apr 2017 15:26:26 -0400 Received: from nm6-vm1.bullet.mail.ne1.yahoo.com ([98.138.91.71]:43717 "EHLO nm6-vm1.bullet.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751486AbdDJT0Y (ORCPT ); Mon, 10 Apr 2017 15:26:24 -0400 X-Yahoo-Newman-Id: 365424.33568.bm@smtp110.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SvOm36YVM1m8FRt5NuUE4NM6winXLo9FpzrxI3KGTkBrVg_ 2OFZTQBWZjW3lJ1HFjWF99V7gDQu7JPGwAykzcrVK_QZ5dTo2GW9UKCLaakM Eo3_Wkbf7xPcdcVYIq_dU4jBGyATDEMMV0Kj4zIIhReHbF.5UCd99ptf.inr tmZ34RYJcpsfmqR_YEYy9DKa6aRh.chFau7FdIyJ3UPPBqb6NNugRwkwWbai 8IxQDJ.xNxVEisgsL8i85FUvqMarelXYriIgF.JFT7q6W2o28o8vUOagS95b wvfAuN4_zMMeNHj9.ZgeZfxTLrZbQoiDQJF_8cp9nW440RI8ibaV1uHg6ia_ v_UlM8DP75ksKGjnT.grj.asvw3IjvVlkBrtBpZW40J.TjvggxgwXRJNWIzm uIP96nKYgLRqu4xzh96.SPbAyR396tsBdsMIwtBTZTL0KhmSBZx_XlX3CXcU qaOfNXqee83bjAdk9s5JmW9iXFa9zIXYCNimplgc6IHiZcqJBtP_Bqh08GZr PsterqD2BpP9qGd3Cnf4fKRh8uYpAfp_PCZi3zMDo.sSoB6k- X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct task_struct" blob. To: Djalal Harouni References: <1491734530-25002-1-git-send-email-tixxdz@gmail.com> <1491734530-25002-2-git-send-email-tixxdz@gmail.com> Cc: Linux Kernel Mailing List , Andy Lutomirski , Kees Cook , Andrew Morton , kernel-hardening@lists.openwall.com, LSM List , Linux API , Dongsu Park , James Morris , "Serge E. Hallyn" , Paul Moore , Tetsuo Handa , Greg Kroah-Hartman From: Casey Schaufler Message-ID: <2698e97b-397e-0fc0-84a1-dc9a4226117a@schaufler-ca.com> Date: Mon, 10 Apr 2017 12:26:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/10/2017 11:30 AM, Djalal Harouni wrote: > On Mon, Apr 10, 2017 at 5:50 PM, Casey Schaufler wrote: >> On 4/9/2017 3:42 AM, Djalal Harouni wrote: >>> From: Tetsuo Handa >>> >>> Since several modules are planning to use per "struct task_struct" blob, >>> we need a layer for isolating it. Therefore, this patch introduces per LSM >>> module per "struct task_struct" blob. >>> >>> It would be possible to remember location in security_hook_heads.task_alloc >>> list and undo up to the corresponding security_hook_heads.task_free list >>> when task_alloc hook failed. But this patch calls all task_free hooks >>> without checking whether the corresponding task_alloc hook was called >>> since most modules should be able to handle this correctly. >>> >>> How to calculate amount of needed bytes and allocate memory for initial >>> task is a chicken-or-egg syndrome. We need to know how many bytes needs >>> to be allocated for initial task's security blobs before security_init() >>> is called. But security_reserve_task_blob_index() which calculates amount >>> of needed bytes is called from security_init(). We will need to split >>> module registration into three steps. The first step is call >>> security_reserve_task_blob_index() on all modules which should be >>> activated. The second step is allocate memory for the initial task's >>> security blob. The third step is actually activate all modules which >>> should be activated. >>> >>> Signed-off-by: Djalal Harouni >>> Signed-off-by: Tetsuo Handa >> While I appreciate your enthusiasm, I would really like >> to see a mechanism for managing all of the blobs as being >> potentially shared rather than just the task blob. With >> infrastructure blob management being the general case we >> could stack any set of existing modules that does not >> include both SELinux and Smack. (AppArmor is threatening >> to join that set, but we're still waiting on that) I > Yes! most of the other kernel maintainers I discussed the feature with > did not even believe or knew that LSM stacking is possible! Some other > kernel frameworks are being replaced with new ones (I'm not sure if > the old ones were perfect!)... but what I'm trying to say is that we > should make it easy for dynamic LSM plugins model so they can explore > the interface, and maybe after some time the whole framework will even > be replaced with a better one... I'm not committing to dynamic modules, but I am working to make sure I don't do anything to prevent someone else from doing it in the future. There are a good number of people who find the notion of dynamic security policy disturbing. > Thanks to your effort and others we may achieve it, but I don't think > that delaying features for a perfect implementation is the best way. > During linuxcon 2016 Europe you said that there should be a new kind > of LSMs, that's why I think we should make it easy for that to happen. I agree that it's better to use a work-around today then to let the shortcomings of the existing infrastructure stop you from getting your job done. > >> think it's a bad idea to go ahead with one implementation >> for task blobs without taking care of the others. > Ok. Sorry if I missed this, but could you please point me why this > could be a bad idea ? It's a whole lot easier to maintain one sort of blob management then a different kind for each blob. It would be lots cleaner to have a single call that tells the infrastructure how much space you need for all your blobs than a separate interface for each. > As I understand it, these are internal details that could be replaced. > My first implementation used resizable concurrent hashtables that are > heavily used in the networking code and it worked, and I easily > converted the module to use Tetsuo's approach since I didn't see any > objection for it, and it continued to work. Maybe the point should be > *which* LSM should use the task->security and how ? The > ModAutoRestrict module is a simple LSM which could easily work with > any provided solution. So I see. > That being said, I could convert the module back and stick with > rhashtables for now since it does not conflict with any module and it > works well. I would like to avoid same history where Apparmor, Smack > and TOMOYO all suffered to get mainlined, even Yama due to some > requests... Then I can convert the module back to use the same LSM > infrastructure if you maintainers think that how it should go, that's > totally fine by me. Yama internally could use the same task blob but > it is avoiding conflicts by using lists to manage its internal data, > that's the same design with ModAutoRestrict and rhashtables. I think that would be the prudent approach. There is still the possibility that blob sharing (or full stacking, if you prefer) won't be accepted any time soon. > Thank you for the comment! >