[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhT0MS9bRAYqMJ6aB+LQXBD3Jpj2sDDOM2gV9vBm5eZK9w@mail.gmail.com>
Date: Thu, 6 Jul 2017 10:36:47 -0400
From: Paul Moore <paul@...l-moore.com>
To: John Stultz <john.stultz@...aro.org>,
Jeffrey Vander Stoep <jeffv@...gle.com>,
Android Kernel Team <kernel-team@...roid.com>
Cc: Stephen Smalley <sds@...ho.nsa.gov>,
lkml <linux-kernel@...r.kernel.org>,
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 9:30 AM, Paul Moore <paul@...l-moore.com> wrote:
> 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.
I'm sorry, I just realized you mentioned AOSP in the subject line ...
In that case Jeffery and the rest of the Android folks are a good
place to start, hopefully they will chime in on this thread with their
plans for supporting these newer kernel features.
--
paul moore
www.paul-moore.com
Powered by blists - more mailing lists