WARNING in apparmor_secid_to_secctx

Dmitry Vyukov dvyukov at google.com
Wed Sep 5 11:08:35 UTC 2018


On Wed, Sep 5, 2018 at 3:21 AM, Paul Moore <paul at 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 at 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 at vger.kernel.org>
>    Reported-by: Dmitry Vyukov <dvyukov at google.com>
>    Reported-by: Waiman Long <longman at redhat.com>
>    Signed-off-by: Stephen Smalley <sds at tycho.nsa.gov>
>    Tested-by: Waiman Long <longman at redhat.com>
>    Signed-off-by: Paul Moore <paul at paul-moore.com>
>
> --
> paul moore
> www.paul-moore.com



More information about the Linux-security-module-archive mailing list