From: dvyukov@google.com (Dmitry Vyukov)
To: linux-security-module@vger.kernel.org
Subject: WARNING in apparmor_secid_to_secctx
Date: Wed, 5 Sep 2018 13:08:35 +0200 [thread overview]
Message-ID: <CACT4Y+YaBpi95Puae3Bjn1opL+UsdUWns2PDaFU-EmamuMusag@mail.gmail.com> (raw)
In-Reply-To: <CAHC9VhR6gG6_RkT1OEH4PArHpzUGkOjVCpKwAmad+TDfC15sgQ@mail.gmail.com>
On Wed, Sep 5, 2018 at 3:21 AM, Paul Moore <paul@paul-moore.com> 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.
Thanks! I've re-enabled selinux on syzbot:
https://github.com/google/syzkaller/commit/196410e4f5665d4d2bf6c818d06f1c8d03cfa8cc
Now we will have instances with apparmor and with selinux.
> * 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 <sds@tycho.nsa.gov>
> 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: <stable@vger.kernel.org>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Reported-by: Waiman Long <longman@redhat.com>
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> Tested-by: Waiman Long <longman@redhat.com>
> Signed-off-by: Paul Moore <paul@paul-moore.com>
>
> --
> paul moore
> www.paul-moore.com
next prev parent reply other threads:[~2018-09-05 11:08 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-30 2:17 WARNING in apparmor_secid_to_secctx syzbot
2018-08-30 2:21 ` Dmitry Vyukov
2018-08-31 16:03 ` Stephen Smalley
2018-08-31 16:07 ` Paul Moore
2018-08-31 16:16 ` Stephen Smalley
2018-08-31 16:17 ` Stephen Smalley
2018-08-31 22:38 ` Dmitry Vyukov
2018-09-04 12:57 ` Stephen Smalley
2018-09-04 13:16 ` Russell Coker
2018-09-04 14:53 ` Dmitry Vyukov
2018-09-05 17:13 ` Kees Cook
2018-09-04 15:02 ` Dmitry Vyukov
2018-09-04 15:28 ` Stephen Smalley
2018-09-04 15:38 ` Dmitry Vyukov
2018-09-04 17:02 ` Stephen Smalley
2018-09-05 1:21 ` Paul Moore
2018-09-05 11:08 ` Dmitry Vyukov [this message]
2018-09-05 17:37 ` Casey Schaufler
2018-09-06 10:59 ` Dmitry Vyukov
2018-09-06 11:19 ` Dmitry Vyukov
2018-09-06 19:35 ` Dmitry Vyukov
2019-01-29 11:32 ` Tetsuo Handa
2019-01-30 14:45 ` Dmitry Vyukov
2019-01-30 16:30 ` Micah Morton
2019-01-31 0:22 ` Tetsuo Handa
2019-02-01 10:09 ` Dmitry Vyukov
2019-02-01 10:11 ` Dmitry Vyukov
2019-02-01 10:43 ` Tetsuo Handa
2019-02-01 10:50 ` Dmitry Vyukov
2019-02-01 13:09 ` [PATCH] LSM: Allow syzbot to ignore security= parameter Tetsuo Handa
2019-02-04 8:07 ` Dmitry Vyukov
2019-02-06 10:23 ` Tetsuo Handa
2019-02-06 17:03 ` Casey Schaufler
2019-02-07 2:30 ` Tetsuo Handa
2019-02-07 16:24 ` Casey Schaufler
2019-02-08 10:52 ` Tetsuo Handa
2019-02-08 16:23 ` Casey Schaufler
2019-02-09 0:28 ` Tetsuo Handa
2019-02-09 1:40 ` Tetsuo Handa
2019-02-08 21:49 ` Kees Cook
2019-02-08 21:33 ` Kees Cook
2018-08-30 3:43 ` WARNING in apparmor_secid_to_secctx syzbot
2018-09-01 9:18 ` John Johansen
2018-09-02 4:33 ` Dmitry Vyukov
2018-09-02 4:52 ` John Johansen
2018-09-02 5:03 ` Dmitry Vyukov
2018-09-02 5:03 ` syzbot
2018-09-02 5:05 ` Dmitry Vyukov
2018-09-02 5:46 ` syzbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACT4Y+YaBpi95Puae3Bjn1opL+UsdUWns2PDaFU-EmamuMusag@mail.gmail.com \
--to=dvyukov@google.com \
--cc=linux-security-module@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).