Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3225603imm; Tue, 4 Sep 2018 18:24:27 -0700 (PDT) X-Google-Smtp-Source: ANB0VdY06XfiCar2eks0rXbOCJ5bDPHijfu0o53xt9NiCKDouaxHsON61Kl/KpZfOQouH0dYlgdL X-Received: by 2002:a17:902:d808:: with SMTP id a8-v6mr36268813plz.68.1536110667389; Tue, 04 Sep 2018 18:24:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536110667; cv=none; d=google.com; s=arc-20160816; b=tJmSSj4yis4CasI2WaWBKnnwWikwLw8HZN/8LWVjw6DCuetiN79QL2mHVYXZZcA9Kh 0BJPwZxgd+G4kNaE/dmO8YY4BNdj4aKWW+hBskcFtK8y7mzr18U9q3pq9pOZHezDeNH+ En8j7h3h8tfnm/slhaUe8GPuab7UpD15+oE2fup0VxavmLZQMV0fL+k+mjtafLgolOFd pst6GeNseybS+mpxB8snpzUwVBwnhcpKR7vGzmJWQE0d20kHG2mHpiupy6Y9KlDkPV4a ExliwcOstMpIEp+vynFUTZVUJ45RhivVZvdhpsFKV0VMf4gcpHxJkxM9FrC016LghkJ2 X6hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0w0PjKyGuT0pxnDu9U9lAoyBrmVujLcu5sAacOGphIY=; b=wR3ZnGIXf5Hs1Fcmuakk6l8wn0uc60biFbilVCmLrx2bxGJr1OEfsDAGDjfW0POLqm 6JV/klMdl5HvKexF5f6qOTZpwZAdt7Q4sRMyAdERsUIIhSKovh8GwtFO64cGHvvLLAW1 O5a5RTALz3wpNfbIZCb8gAinmDXjazV6A0bZAfVRR6xeia8Vunk5igNjSESVhlHp44O5 XzYSvfPGV5xVfcYqI9YZ+rUWDVNVWCpoGgyS9fQQ48djq0y5rbGhcW1FH4RNROIOl7tN X26Rr3d09/h6+1J4ixoPmbboB9sIHAihoSV120PTuUhy4f4a6XXgnLt6wZ2g8P8+nRCL 7lGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=Edp2Yx32; 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 v38-v6si514634plg.179.2018.09.04.18.24.11; Tue, 04 Sep 2018 18:24:27 -0700 (PDT) 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=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=Edp2Yx32; 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 S1726888AbeIEFtD (ORCPT + 99 others); Wed, 5 Sep 2018 01:49:03 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:46378 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726463AbeIEFtD (ORCPT ); Wed, 5 Sep 2018 01:49:03 -0400 Received: by mail-lj1-f193.google.com with SMTP id 203-v6so4731644ljj.13 for ; Tue, 04 Sep 2018 18:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0w0PjKyGuT0pxnDu9U9lAoyBrmVujLcu5sAacOGphIY=; b=Edp2Yx32i8Dj0Uw0fhmjvqTlY3OnfFWpZaLOzlx3VDlkOjLNsNpvx1QE9MjF0UIavn atcEJhTNeusX3IOoFv5IFKxaTCTvhxHO3Mklf9cBlMcLW5awjMfru2i7slcwt3iG7Bww HlL0rPv1lBqWWppzl9fUlQAuWjjEbvNHvSJGOIi9qyJ4Q/Gi22UomX5CkFODDQ89liQM 6Q5BHR69HPClJXiSsaTupBbfcRt+xGsSHSkTHUNg5AmPs3nOQZ+GMWNb3i8gAkGRIh52 N+rsMT14nwc44CVQsYGkn4XpN48C2sYq06ptwkAI8b96QXmDUMNwp8CTSvqIqcEtzirM e0DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0w0PjKyGuT0pxnDu9U9lAoyBrmVujLcu5sAacOGphIY=; b=pnn9h0LZ/U5qQKj7kLZPKwoR/9YHIXLKVUwTeVk+1hmByHXkxpnra61utddFghHelh HQI2b0DpWJjLrvKZ+0H8LLnKnKrbrkOaZ9UEDvgkDYwqrbpGi4/QwiXU33a2aczov7tl RyAuswCTLTLs1wQtvTvtRT/dalRUjgAnVxMBv2jOWXB6tIg3ne96c+FvPutieyjyur1r r2wmHkRWJQFn6NdKE4A2cPDaV0lxCBQG+VKBi8aN/KdrfTjv7uder+UZAX4FfgiHnD0k a3pbRF2h3tOzxKRQoFsjKpb+bonQEou9pr850eXmEE70G3nud6Cb0+En/teDYUC9BQ7v Q7fw== X-Gm-Message-State: APzg51CLixRRqlyXTX0/nhK7yL4j1R09MkskFSpKAXLCqVkQhwFLnE1h SfICOhVRkVVby3QbSObuEF1A2UXJJoorhXnZCmL6 X-Received: by 2002:a2e:7c12:: with SMTP id x18-v6mr9315565ljc.71.1536110480066; Tue, 04 Sep 2018 18:21:20 -0700 (PDT) MIME-Version: 1.0 References: <000000000000c178e305749daba4@google.com> <37aec45f-69ad-9705-21f1-64ee4ce4a772@tycho.nsa.gov> <9537a6ff-daf4-d572-bf93-68230909b68e@tycho.nsa.gov> <4b37e892-4d79-aefb-92ab-7753b89b8963@tycho.nsa.gov> <1ea19628-3bbe-2073-d623-824337c15ed6@tycho.nsa.gov> <6c9112a2-33f3-0c29-c944-1d129a0026e7@tycho.nsa.gov> In-Reply-To: <6c9112a2-33f3-0c29-c944-1d129a0026e7@tycho.nsa.gov> From: Paul Moore Date: Tue, 4 Sep 2018 21:21:08 -0400 Message-ID: Subject: Re: WARNING in apparmor_secid_to_secctx To: Stephen Smalley Cc: dvyukov@google.com, syzbot+21016130b0580a9de3b5@syzkaller.appspotmail.com, tyhicks@canonical.com, john.johansen@canonical.com, James Morris , linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Serge Hallyn , syzkaller-bugs@googlegroups.com, jeffv@google.com, selinux@tycho.nsa.gov, russell@coker.com.au, bigon@debian.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 4, 2018 at 1:00 PM Stephen Smalley wrote: > On 09/04/2018 11:38 AM, Dmitry Vyukov wrote: > > On Tue, Sep 4, 2018 at 5:28 PM, Stephen Smalley wrote: > >>>> So why not ask for help from the SELinux community? I've cc'd the selinux > >>>> list and a couple of folks involved in Debian selinux. I see a couple of > >>>> options but I don't know your constraints for syzbot: > >>>> > >>>> 1) Run an instance of syzbot on a distro that supports SELinux enabled > >>>> out > >>>> of the box like Fedora. Then you don't have to fight with SELinux and can > >>>> just focus on syzbot, while still testing SELinux enabled and enforcing. > >>>> > >>>> 2) Report the problems you are having with enabling SELinux on newer > >>>> Debian > >>>> to the selinux list and/or the Debian selinux package maintainers so that > >>>> someone can help you resolve them. > >>>> > >>>> 3) Back-port the cgroup2 policy definitions to your wheezy policy, > >>>> rebuild > >>>> it, and install that. We could help provide guidance on that. I think > >>>> you'll need to rebuild the base policy on wheezy; in distributions with > >>>> modern SELinux userspace, one could do it just by adding a CIL module > >>>> locally. > >>> > >>> > >>> Thanks, Stephen! > >>> > >>> I would like to understand first if failing mount(2) for unknown fs is > >>> selinux bug or not. Because if it is and it is fixed, then it would > >>> resolve the problem without actually doing anything (well, at least on > >>> our side :)). > >> > >> > >> Yes, I think that's a selinux kernel regression, previously reported here: > >> https://lkml.org/lkml/2017/10/6/658 > >> > >> Unfortunately I don't think it has been fixed upstream. Generally people > >> using SELinux with a newer kernel are also using a newer policy. That said, > >> I agree it is a regression and ought to be fixed. > > > > > > How hard is it to fix it? We are on upstream head, so once it's in we > > are ready to go. > > Using multiple images is somewhat problematic (besides the fact that I > > don't know how to build a fedora image) because syzbot does not > > capture what image was used, and in the docs we just provide the > > single image, so people will start complaining that bugs don't > > reproduce but they are just using a wrong image. > > I'll take a look and see if I can provide a trivial fix. As a FYI, Stephen provided a patch and it has been merged into the selinux/next tree. * git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git * https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git Author: Stephen Smalley Date: Tue Sep 4 16:51:36 2018 -0400 selinux: fix mounting of cgroup2 under older policies commit 901ef845fa2469c ("selinux: allow per-file labeling for cgroupfs") broke mounting of cgroup2 under older SELinux policies which lacked a genfscon rule for cgroup2. This prevents mounting of cgroup2 even when SELinux is permissive. Change the handling when there is no genfscon rule in policy to just mark the inode unlabeled and not return an error to the caller. This permits mounting and access if allowed by policy, e.g. to unconfined domains. I also considered changing the behavior of security_genfs_sid() to never return -ENOENT, but the current behavior is relied upon by other callers to perform caller-specific handling. Fixes: 901ef845fa2469c ("selinux: allow per-file labeling for cgroupfs") CC: Reported-by: Dmitry Vyukov Reported-by: Waiman Long Signed-off-by: Stephen Smalley Tested-by: Waiman Long Signed-off-by: Paul Moore -- paul moore www.paul-moore.com