linux-kernel - Re: [Regression?] "selinux: add a map permission check for mmap" causing AOSP to fail booting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhQk1BYzoBvKLEukHcgdpFjUeXTE2PVU_2yz1fcV5O4Phw@mail.gmail.com>
Date:   Thu, 6 Jul 2017 09:30:11 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     John Stultz <john.stultz@...aro.org>
Cc:     Stephen Smalley <sds@...ho.nsa.gov>,
        Jeffrey Vander Stoep <jeffv@...gle.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        Nick Kralevich <nnk@...gle.com>,
        Kees Cook <keescook@...gle.com>,
        Dmitry Shmidt <dimitrysh@...gle.com>
Subject: Re: [Regression?] "selinux: add a map permission check for mmap"
 causing AOSP to fail booting

On Thu, Jul 6, 2017 at 1:32 AM, John Stultz <john.stultz@...aro.org> wrote:
> Hey folks,
>    I updated my HiKey kernel tree to linus/master today and it stopped
> booting (hitting errors at init and reseting immediately into
> bootloader mode):
>
> [    5.289827] init: Skipped setting INIT_AVB_VERSION (not in recovery mode)
> [    5.296709] init: Loading SELinux policy
> [    5.334521] SELinux:  Permission validate_trans in class security
> not defined in policy.
> [    5.342828] SELinux:  Permission map in class file not defined in policy.
> [    5.349690] SELinux:  Permission map in class dir not defined in policy.
> [    5.356464] SELinux:  Permission map in class lnk_file not defined in policy.
> [    5.363666] SELinux:  Permission map in class chr_file not defined in policy.
> [    5.370870] SELinux:  Permission map in class blk_file not defined in policy.
> [    5.378070] SELinux:  Permission map in class sock_file not defined
> in policy.
> [    5.385351] SELinux:  Permission map in class fifo_file not defined
> in policy.
> [    5.392647] SELinux:  Permission map in class socket not defined in policy.
> [    5.399670] SELinux:  Permission map in class tcp_socket not
> defined in policy.
> [    5.407042] SELinux:  Permission map in class udp_socket not
> defined in policy.
> [    5.414415] SELinux:  Permission map in class rawip_socket not
> defined in policy.
> [    5.421969] SELinux:  Permission map in class netlink_socket not
> defined in policy.
> ...
> [    5.850590] SELinux: the above unknown classes and permissions will be denied
> [    5.892283] audit: type=1403 audit(104.182:2): policy loaded
> auid=4294967295 ses=4294967295
> [    5.892510] selinux: SELinux: Loaded policy from /sepolicy
> [    5.892510]
> [    5.907690] audit: type=1404 audit(104.183:3): enforcing=1
> old_enforcing=0 auid=4294967295 ses=4294967295
> [    5.911853] selinux: selinux_android_file_context: Error getting
> file context handle (Permission denied)
> [    5.911853]
> [    5.911968] init: execv("/init") failed: Permission denied
> [    5.911987] init: Security failure...
> [    5.912008] init: panic: rebooting to bootloader
> [    5.912034] init: Reboot start, reason: reboot, rebootTarget: bootloader
>
>
> I bisected the issue down to 3ba4bf5f1e2c (selinux: add a map
> permission check for mmap).
>
> It seems every -rc1 I hit something like this w/ selinux, and
> sometimes it is just that I need to fix my sepolicy files, but I'm not
> really sure which this one is.
>
> Reverting the identified commit allows things to boot normally.

Hello,

The short version is that this is the expected behavior given your
SELinux policy configuration and isn't a regression; your SELinux
policy is configured to not be overly permissive when new access
control points are introduced and that is what it is doing.

The slightly longer version is that your SELinux policy is set to deny
access to any new object classes or permissions that are not defined
in the policy, and we can see from your boot output your SELinux
policy does not define the new "map" permission for a number of object
classes.  The solution is to either update your SELinux policy to
include the SELinux policy, or to allow unknown object classes and
permissions.

What distribution are you running (where are you getting your SELinux
policy and userspace)?  I would suggest starting a conversation there,
I'm happy to lend a hand if you need some help explaining the
situation.

-- 
paul moore
www.paul-moore.com