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

[Stephen Smalley <sds@tycho.nsa.gov>]

On Thu, 2017-07-06 at 10:36 -0400, Paul Moore wrote:
> On Thu, Jul 6, 2017 at 9:30 AM, Paul Moore <paul@paul-moore.com>
> wrote:
> > On Thu, Jul 6, 2017 at 1:32 AM, John Stultz <john.stultz@linaro.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.

Try this change to your policy:
https://android-review.googlesource.com/#/c/432339/