Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1855965imj; Fri, 8 Feb 2019 08:25:43 -0800 (PST) X-Google-Smtp-Source: AHgI3IZOaSPDLcZoudnvK0Hnnuz9+aOjiA8sOjkmjO+DCT1jZq/D8WVWoVJ4vXs7d/Zy3lRb1zcr X-Received: by 2002:a62:2547:: with SMTP id l68mr22721400pfl.131.1549643143402; Fri, 08 Feb 2019 08:25:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549643143; cv=none; d=google.com; s=arc-20160816; b=u9T8zkVYpy4R1Wqv5l9zCVlZf2p9y4Kmz1iuWrpEY3dFIhhBuJlDvY2EmevAxktR85 YU4EoYI+MPWzBVOadRZDa/v4+V7I8ekLbpRBLIVQY8sBuqhtYdOfeoi9u089ujcFmYZv pkskpXKAqB3zsOW4yU6GCp7c3HO0ViAj2zexyBls3Kd89J5xuaFtlZDuT5uSmJakRbMz cCLOpdHRP8oJQdd1lODqiiF6Sae2dUiLSR0SD3wfG7VXM1P9PE17Fs821BHKU3hpsUhX 55D/1V0iNOyPRFk+jOZQG6dm8GichnngQkhzvLoweXl/7NAlAdY7e9lbnc9SOnrH4bfi fJLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=IC3IiwCaqlr7p1SEalNKlIG0zEiTWg9gQZ5/fBeSm1s=; b=HRYGYURGXAb/dltS4Pm9ezRzWo9+B8MFeRdh1iI9/4khNUH01gYq2Yq11IXmr9Q06v 2GzQbS3JxDR9GbYAwM+nUX1lS1f1jAHzP2hMFjXBGhrSF6TRCyFI2C51QTTkvgfL+IK/ C/Nh4l9v3P23ZFT4t0fmcbVagxyGphFOgQkLMYm5TSVXUx2m8F1s9Y6kbiAEBsf/PVQC gaC/15uAmDUypW4JyO9u2yopKpErYi88IqH3nqpYH9Uf2BSkO8lLUu9uvAN6NPVQj2yt aChNOy+fMVkkNKjMY9Rs10fV6oZZHXoUKJhjdg6OgvEZnesIc8oTxFRNtFbPFaC6dYd/ IGpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yahoo.com header.s=s2048 header.b=gVd7DXHX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y12si2537331plk.174.2019.02.08.08.25.26; Fri, 08 Feb 2019 08:25:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@yahoo.com header.s=s2048 header.b=gVd7DXHX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727591AbfBHQXm (ORCPT + 99 others); Fri, 8 Feb 2019 11:23:42 -0500 Received: from sonic315-14.consmr.mail.gq1.yahoo.com ([98.137.65.38]:35313 "EHLO sonic315-14.consmr.mail.gq1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727139AbfBHQXl (ORCPT ); Fri, 8 Feb 2019 11:23:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1549643020; bh=IC3IiwCaqlr7p1SEalNKlIG0zEiTWg9gQZ5/fBeSm1s=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=gVd7DXHX92ehR+jvCEROLXb0JTH5AFkgiWDSzZyKYKjcvV6DRDwOZzcd1k+pOE7hW0rfnyRkrMrHWF+FdAPaN2D7F5TnMMVvqI0EmW5EDNMCVaIBN8Rs9B5rlSsgQZtcKkrM2SA00J5orFE0a/NIoDVal+JTOoTZnAHep/fypy5htZWMqAGN1LhHpYUXxlVkWQ7DRYV9dvDrQsBiEGMNsux7KNd86xqT50+LijU+6FR6Z8kxW4U2IQqv1/ZbPU9cDM+DP8aC9wb3dSgGx0u9wIsaPTF7LrneTx4tX/0ezJTrATAa4z4FgzOw9ELMZ0kXUoFIR928tfFL+Zt+plO5oQ== X-YMail-OSG: DsBtFVwVM1kxy5RZnl.ZYHAGzz9Jl5RvBDNm5uDx2XiT9Gh26iuhF_tVwTfJl6b CPqHytCH1ost.I49OMApNL4CdWtCpKoAfNeIEQaQXk2e7NvpQrcXJ4eVc0HDOA4jryYUsYOHksWc uyxQPsxe57gtwizIQTf9aA8xwvZgxIbRDz4dU_wRygETT9Z7ribPTQNe1nqCxUGyZFDKwvJBVWZa LVxZf1Q1v1V2MjySevuxcBGc7po6O6cerhttqwTxb4K84yoAOVN13AWsm18cdmePRgBXxnOWVwkd 8Gdhb8f4gqiSsTmMTBSOEhbbDWQREJUgeZFS75UfbS9ucrIWKXJu8oALdIS4Zklmyyck0LASv1oP KPlcwvi7I387xf9_mfRf2Wga_8qTMAocZwx8YUKB3fmfQ5GpZ7.a8bk9O_afLX56uxRkUu8jVLhG H1jQzpthdTwMJGlv6eVXBzVhmY.fYTiurI4g_.xnjXWphsm_ZtOz3.275OZE6D1oT_ILjaik0ynH JcpxH69ns5AWNgcfoZCG5tZRhpUsVKt4_17vMAQtttSvRd3i8YyQQju6unQQuDQMXYq.F0m0cS9k zi1HMVptGAmGexRjmptWjuKa.c6md4sUIt5t6sSWrDXYRO2gTMbqHq8GO.4ugi1P14psAMpcc48a ewvBczDGr3d1O0OjJrwLK9ahW6WRyLR_Z6MZIEF9ayyxHYA1NorLYFZed1NIq5O.AC_igV6zWKc_ vlquB29wBY_HFW3Yy.tDw.zO71oY5S6V5pR2jxx7rQnhgKzV3XWKwGMeK_jKgBrsja.qYKz5mOv. DPneyDDOvE1U5Nqbd8n9CdWH81ge4.D3gIyqC2gPW9Ih_fYo7We_xpvWr0Jts5mjggamAp5yAEoG m740oIGJbJAPpUpcyBElCExyH101v_SspuhgLILkNHS_rwklmgcJ5U0zF78JAdWlCCSqonP2RNfX mGfHTymp08o9Hnp3ZJcuqRdLCSp6yd0V05vLmLbf2bn2F34jK6i17CrN_HKae3gEFhHYiCIMBmLb klT_auBBWy_ptK1LILHDjGr0QPCputZzHFQxbw4vnISEke28VRHe_HtMuQ9LkwhPU3OuvFlRe_4f KJ_pSEctfeYsAg1Vgq5HChcva Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 8 Feb 2019 16:23:40 +0000 Received: from c-67-169-65-224.hsd1.ca.comcast.net (EHLO [192.168.0.100]) ([67.169.65.224]) by smtp417.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f45be69ab64a31d2d3163059690a45a1; Fri, 08 Feb 2019 16:23:36 +0000 (UTC) Subject: Re: [PATCH] LSM: Allow syzbot to ignore security= parameter. To: Tetsuo Handa , Kees Cook Cc: Dmitry Vyukov , Paul Moore , Stephen Smalley , syzbot , tyhicks@canonical.com, John Johansen , James Morris , LKML , linux-security-module@vger.kernel.org, Serge Hallyn , syzkaller-bugs , Jeffrey Vander Stoep , SELinux , Russell Coker , Laurent Bigonville , syzkaller , Andrew Morton References: <8f48e1d0-c109-f8a9-ea94-9659b16cae49@i-love.sakura.ne.jp> <0d23d1a5-d4af-debf-6b5f-aaaf698daaa8@schaufler-ca.com> <201902070230.x172UUG6002087@www262.sakura.ne.jp> <6def6199-0235-7c37-974c-baf731725606@schaufler-ca.com> <54c0ae39-f35c-bdcd-a217-8e62ef14e41b@i-love.sakura.ne.jp> From: Casey Schaufler Message-ID: <54f15845-f256-f503-98ce-64a1b88a5f9f@schaufler-ca.com> Date: Fri, 8 Feb 2019 08:23:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <54c0ae39-f35c-bdcd-a217-8e62ef14e41b@i-love.sakura.ne.jp> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/8/2019 2:52 AM, Tetsuo Handa wrote: > On 2019/02/08 1:24, Casey Schaufler wrote: >>>>> Then, I think that it is straightforward (and easier to manage) to ignore security= parameter >>>>> when lsm= parameter is specified. >>>> That reduces flexibility somewhat. If I am debugging security modules >>>> I may want to use lsm= to specify the order while using security= to >>>> identify a specific exclusive module. I could do that using lsm= by >>>> itself, but habits die hard. >>> "lsm=" can be used for identifying a specific exclusive module, and Ubuntu kernels would >>> have to use CONFIG_LSM (or "lsm=") for identifying the default exclusive module (in order >>> to allow enabling both TOMOYO and one of SELinux,Smack,AppArmor at the same time). >>> >>> Since "security=" can't be used for selectively enable/disable more than one of >>> SELinux,Smack,TOMOYO,AppArmor, I think that recommending users to migrate to "lsm=" is the >>> better direction. And ignoring "security=" when "lsm=" is specified is easier to understand. >> I added Kees to the CC list. Kees, what to you think about >> ignoring security= if lsm= is specified? I'm ambivalent. >> >> > To help administrators easily understand what LSM modules are possibly enabled by default (which > have to be fetched from e.g. /boot/config-`uname -r`) $ cat /sys/kernel/security/lsm > and specify lsm= parameter when they need, > I propose changes shown below. > > diff --git a/security/security.c b/security/security.c > index 3147785e..051d708 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -51,8 +51,6 @@ > static __initdata const char *chosen_lsm_order; > static __initdata const char *chosen_major_lsm; > > -static __initconst const char * const builtin_lsm_order = CONFIG_LSM; > - > /* Ordered list of LSMs to initialize. */ > static __initdata struct lsm_info **ordered_lsms; > static __initdata struct lsm_info *exclusive; > @@ -284,14 +282,22 @@ static void __init ordered_lsm_parse(const char *order, const char *origin) > static void __init ordered_lsm_init(void) > { > struct lsm_info **lsm; > + const char *order = CONFIG_LSM; > + const char *origin = "builtin"; > > ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms), > GFP_KERNEL); > > - if (chosen_lsm_order) > - ordered_lsm_parse(chosen_lsm_order, "cmdline"); > - else > - ordered_lsm_parse(builtin_lsm_order, "builtin"); > + if (chosen_lsm_order) { > + if (chosen_major_lsm) { > + pr_info("security= is ignored because of lsm=\n"); > + chosen_major_lsm = NULL; > + } > + order = chosen_lsm_order; > + origin = "cmdline"; > + } > + pr_info("Security Framework initializing: %s\n", order); > + ordered_lsm_parse(order, origin); > > for (lsm = ordered_lsms; *lsm; lsm++) > prepare_lsm(*lsm); > @@ -333,8 +339,6 @@ int __init security_init(void) > int i; > struct hlist_head *list = (struct hlist_head *) &security_hook_heads; > > - pr_info("Security Framework initializing\n"); > - > for (i = 0; i < sizeof(security_hook_heads) / sizeof(struct hlist_head); > i++) > INIT_HLIST_HEAD(&list[i]); I'm not going to object to this, but I don't see it as important.