From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D597BC282D8 for ; Fri, 1 Feb 2019 10:44:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AE51821872 for ; Fri, 1 Feb 2019 10:44:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729778AbfBAKon (ORCPT ); Fri, 1 Feb 2019 05:44:43 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:15984 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726428AbfBAKon (ORCPT ); Fri, 1 Feb 2019 05:44:43 -0500 Received: from fsav108.sakura.ne.jp (fsav108.sakura.ne.jp [27.133.134.235]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id x11Ahn4f050776; Fri, 1 Feb 2019 19:43:49 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav108.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav108.sakura.ne.jp); Fri, 01 Feb 2019 19:43:49 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav108.sakura.ne.jp) Received: from [192.168.1.8] (softbank126126163036.bbtec.net [126.126.163.36]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id x11AhhAu050719 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2019 19:43:48 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: WARNING in apparmor_secid_to_secctx To: Dmitry Vyukov Cc: Casey Schaufler , 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 References: <000000000000c178e305749daba4@google.com> <4b37e892-4d79-aefb-92ab-7753b89b8963@tycho.nsa.gov> <1ea19628-3bbe-2073-d623-824337c15ed6@tycho.nsa.gov> <6c9112a2-33f3-0c29-c944-1d129a0026e7@tycho.nsa.gov> <05340d28-36c2-267e-d54e-416fddfba211@i-love.sakura.ne.jp> From: Tetsuo Handa Message-ID: <71e3652b-b222-0c3f-8b48-5980ddcaeb93@i-love.sakura.ne.jp> Date: Fri, 1 Feb 2019 19:43:39 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/02/01 19:09, Dmitry Vyukov wrote: > Thanks for the explanations. > > Here is the change that I've come up with: > https://github.com/google/syzkaller/commit/aa53be276dc84aa8b3825b3416542447ff82b41a You are not going to apply this updated config to upstream kernels now, are you? Removing CONFIG_DEFAULT_SECURITY="apparmor" from configs used by upstream kernels will cause failing to enable AppArmor (unless security=apparmor is specified). I guess you can apply this updated config to linux-next kernels given that you replace CONFIG_LSM="yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor" with CONFIG_LSM="yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo" so that AppArmor is enabled instead of SELinux. > > I've disabled CONFIG_SECURITY_TOMOYO_OMIT_USERSPACE_LOADER (it > actually looked like omitting a user-space loader that I don't have is > the right thing to do, but okay, it indeed does not with =y). > > For now I just enabled TOMOYO and SAFESETID. > I see the problem with making both linux-next and upstream work. If we > use a single config and lsm= cmdline argument, then on upstream all > kernels will use the same module (they won't understand lsm=). But if > we add security= then it will take precedence over lsm= on linux-next, > so we won't get stacked modules. Right. > > Let's go with (c) because I don't want an additional long-term maintenance cost. OK. > If I understand it correctly later we will need to replace: > security=selinux > security=smack > security=apparmor > > with: > lsm=yama,safesetid,integrity,selinux,tomoyo > lsm=yama,safesetid,integrity,smack,tomoyo > lsm=yama,safesetid,integrity,tomoyo,apparmor Yes. Thank you.