[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1499695041.7580.1.camel@tycho.nsa.gov>
Date: Mon, 10 Jul 2017 09:57:21 -0400
From: Stephen Smalley <sds@...ho.nsa.gov>
To: Paul Moore <paul@...l-moore.com>,
John Stultz <john.stultz@...aro.org>,
Jeffrey Vander Stoep <jeffv@...gle.com>,
Android Kernel Team <kernel-team@...roid.com>
Cc: 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, 2017-07-06 at 10:36 -0400, Paul Moore wrote:
> 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.
Try this change to your policy:
https://android-review.googlesource.com/#/c/432339/
Powered by blists - more mailing lists