Re: init: SELinux: Could not load policy

2018-04-12 Thread kiran mardi
Hi Stephen,

it is a field issue and we see only on 1 set. it is seen on android N set.
it is strange that it is seen on only 1 set. can it be hardware issue? DDR
issue since we see ebitmap is giving different data?.

On Wed, Apr 11, 2018 at 7:08 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote:

> On 04/11/2018 06:12 AM, kiran mardi wrote:
> > Hi All,
> >
> > I see in one of my device getting the selinux policy loading error
> during init first stage.
> > however the logs give every boot different error w.r.t selinux policy
> loading.
> >
> > 1st bootup of set:
> >
> > [7.933699] init: SELinux:  Could not load policy:  Out of memory
> > [7.938900] init: failed to load policy: Out of memory
> > [7.943884] init: Security failure; rebooting into recovery mode...
> >
> >
> > 2nd bootup[to recovery]:
> >
> > [ 7.028166] SELinux: ebitmap start bit (*400*) is not a multiple of the
> map unit size (64)
> > [7.035557] init: SELinux:  Could not load policy:  Invalid argument
> > [7.041652] init: failed to load policy: Invalid argument
> > [7.047031] init: Security failure; rebooting into recovery mode...
> >
> >
> > 3rd bootup[to recovery]:
> >
> > [ 7.622606] SELinux: ebitmap: map size *1048640 *does not match my size
> 64 (high bit was 0)
> >  [7.630081] init: SELinux:  Could not load policy:  Invalid argument
> >  [7.636214] init: failed to load policy: Invalid argument
> > [7.641447] init: Security failure; rebooting into recovery mode...
> >
> >
> > is it problem with my kernel allocating memory for selinux sys/fs?
> > can i suspect RAM not working properly?
>
> Sounds like the policy is corrupted.  Can you confirm that the policy file
> itself is valid, e.g. on the build host, run seinfo on the policy file?
>
> Does your kernel match your policy?  There was an incompatible change in
> policy format between Android 6 Marshmallow and Android 7 Nougat; Google
> provided a backward compatibility patch in their common kernels so that
> Android 7 kernels could still load older policies.
>
>


-- 
regards,
kiran mardi


Re: /data/misc contents are unlabeled

2018-03-09 Thread kiran mardi
Hi Stephen,

The issue I am mentioning is not 100% reproducible. We are seeing this very
rarely. So don't know how to get this reproduce. Anyway will try to get
more details on the issue and get back to u.

Was also thinking what else can be added to address this.

Thanks for your help.

On 09-Mar-2018 6:41 PM, "Stephen Smalley" <s...@tycho.nsa.gov> wrote:

> On 03/09/2018 02:55 AM, kiran mardi wrote:
> > >>>>>>>>sh-3.2# toybox restorecon -nv /data/misc/dhcp
> >
> > [  158.754324] type=1400 audit(946742542.500:16): avc: denied { search }
> for pid=983 comm="toybox" name="security" dev="mmcblk0p7" ino=186945
> scontext=u:r:shell:s0 tcontext=u:object_r:security_file:s0 tclass=dir
> permissive=1
> >
> > SELinux: Loaded file_contexts contexts from /file_contexts.bin.[
> 158.776446] type=1400 audit(946742542.520:17): avc: denied { getattr } for
> pid=983 comm="toybox" path="/data/misc/dhcp" dev="mmcblk0p7" ino=406419
> scontext=u:r:shell:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
> permissive=1
> >
> >
> >
> > SELinux:  Relabeling /data/misc/dhcp from u:object_r:unlabeled:s0 to
> u:object_r:dhcp_data_file:s0.
>
> Ok, so you have a valid context for /data/misc/dhcp in your file_contexts,
> which should have been used if the restorecon_recursive /data executed.
>
> Did your file_contexts configuration change between the old and new
> versions?  restorecon_recursive /data will skip the tree walk if
> file_contexts has not changed since the last time it was run; this is based
> on a separate security.restorecon_last xattr set on the /data directory
> with the SHA1 hash of the /file_contexts.bin file.
>
> Also, what was the context on /data/misc/dhcp in the prior version from
> which you are upgrading?  Was it the same or different?  If different, what
> was it?
>
>


Re: Re: /data/misc contents are unlabeled

2018-03-08 Thread kiran mardi
Hi Stephen,

Please find my replay below inline.

Regards,
Kiran Mardi

On Thu, Mar 8, 2018 at 10:57 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote:

> On 03/08/2018 12:05 PM, kiran mardi wrote:
> > Hi Stephen,
> >
> > Please find my response inline.
> >
> > Regards,
> > Kiran Mardi
> >
> > On Thu, Mar 8, 2018 at 8:56 PM, Stephen Smalley <s...@tycho.nsa.gov
> <mailto:s...@tycho.nsa.gov>> wrote:
> >
> > Is this on AOSP master or a particular release branch?
> > [Kiran]: it is particular release branch Android N.
>
> Which one?
> >>>>[Kiran]: 7.1.2
> >
> >
> >
> > Is this occurring on a clean install or on an upgrade from a
> previous version?
> >
> > [Kiran]: It is upgrade from previous version.
>
> Which previous version, and was SELinux enabled in that version?
>
>>>>>>> [Kiran]yes, it is same Android N(SELinux was enforced) we are
giving some updates on N.

>
> > There should be a recursive restorecon by init.rc of /data already
> from post-fs-data which should label everything.
> > [Kiran]: yes, from my archive the restorecon is part of init.rc but
> it is not recursive. is this the root cause?
> >
> > 349 <http://2k16-xref.tpvision.com:8080/source/xref/MTK_N_NEWSTR
> UCT/android/n-base/system/core/rootdir/init.rc#349> # We restorecon /data
> in case the userdata partition has been reset. 350 <
> http://2k16-xref.tpvision.com:8080/source/xref/MTK_N_NEWSTR
> UCT/android/n-base/system/core/rootdir/init.rc#350> restorecon /data
>
> That one is just to fix the label on the top directory upon a reset of
> userdata; if you look further down in the init.rc file you should find this
> line:
>   # Set SELinux security contexts on upgrade or policy update.
> restorecon_recursive /data
>
> It is there in AOSP's nougat-mr2.3-release branch, for example.
> >>>>>>>[Kiran]:my bad saw the recursive restorecon in the end.
>
>>>>>>>

>>>>>>>>sh-3.2# toybox restorecon -nv /data/misc/dhcp

[  158.754324] type=1400 audit(946742542.500:16): avc: denied { search }
for pid=983 comm="toybox" name="security" dev="mmcblk0p7" ino=186945
scontext=u:r:shell:s0 tcontext=u:object_r:security_file:s0 tclass=dir
permissive=1

SELinux: Loaded file_contexts contexts from /file_contexts.bin.[
158.776446] type=1400 audit(946742542.520:17): avc: denied { getattr } for
pid=983 comm="toybox" path="/data/misc/dhcp" dev="mmcblk0p7" ino=406419
scontext=u:r:shell:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
permissive=1



SELinux:  Relabeling /data/misc/dhcp from u:object_r:unlabeled:s0 to
u:object_r:dhcp_data_file:s0.

>
> >
> >
> > Is there perhaps an invalid context in your file_contexts
> configuration for these directories?
> > Does it pass checkfc validation against your policy file?
> > [Kiran]: no there are no invalid file_contexts and never got any
> compilation error.
> >
> >
> >
> > What does a restorecon -nv /data/misc/dhcp report from an adb shell?
> > [Kiran]: will get back on the result.
> >
> >
> >
> > On 03/08/2018 10:14 AM, kiran mardi wrote:
> > > some more data to the below issue. below are the folders which
> have become unlabeled dont know the relation though.
> > >
> > > drwxrwxr-x  2 dhcp dhcp u:object_r:unlabeled:s0
>24576 2013-03-30 16:44 dhcp
> > > drwxrwx---  2 system   system   u:object_r:unlabeled:s0
>24576 1995-09-25 03:39 ethernet
> > > drwx--  2 mediamediau:object_r:unlabeled:s0
>24576 1995-09-25 03:39 media
> > > drwxrwxr-x  2 system   cacheu:object_r:unlabeled:s0
>24576 2013-10-19 10:47 onehelp
> > > drwxrwxr-x  2 root root u:object_r:unlabeled:s0
>24576 1995-09-25 03:39 perfprofd
> > > drwxrwx--x  3 root root u:object_r:unlabeled:s0
>24576 2000-01-01 16:05 user
> > > drwx--  2 root root u:object_r:unlabeled:s0
>24576 1995-09-25 03:39 vold
> > >
> > >
> > > On Thu, Mar 8, 2018 at 7:13 PM, kiran mardi <mardiki...@gmail.com
> <mailto:mardiki...@gmail.com> <mailto:mardiki...@gmail.com  mardiki...@gmail.com>>> wrote:
> > >
> > > Hi All,
> > >
> > > In one of our set we are seeing /data/misc/netd, keystore,
> user as unlabel

Re: /data/misc contents are unlabeled

2018-03-08 Thread kiran mardi
Hi Stephen,

Please find my response inline.

Regards,
Kiran Mardi

On Thu, Mar 8, 2018 at 8:56 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote:

> Is this on AOSP master or a particular release branch?
> [Kiran]: it is particular release branch Android N.



> Is this occurring on a clean install or on an upgrade from a previous
> version?
>
[Kiran]: It is upgrade from previous version.

>
> There should be a recursive restorecon by init.rc of /data already from
> post-fs-data which should label everything.
> [Kiran]: yes, from my archive the restorecon is part of init.rc but it is
> not recursive. is this the root cause?
>
349 
<http://2k16-xref.tpvision.com:8080/source/xref/MTK_N_NEWSTRUCT/android/n-base/system/core/rootdir/init.rc#349>
   # We restorecon /data in case the userdata partition has been
reset.350 
<http://2k16-xref.tpvision.com:8080/source/xref/MTK_N_NEWSTRUCT/android/n-base/system/core/rootdir/init.rc#350>
   restorecon /data



> Is there perhaps an invalid context in your file_contexts configuration
> for these directories?
> Does it pass checkfc validation against your policy file?
> [Kiran]: no there are no invalid file_contexts and never got any
> compilation error.
>


> What does a restorecon -nv /data/misc/dhcp report from an adb shell?
> [Kiran]: will get back on the result.
>


> On 03/08/2018 10:14 AM, kiran mardi wrote:
> > some more data to the below issue. below are the folders which have
> become unlabeled dont know the relation though.
> >
> > drwxrwxr-x  2 dhcp dhcp u:object_r:unlabeled:s0
>  24576 2013-03-30 16:44 dhcp
> > drwxrwx---  2 system   system   u:object_r:unlabeled:s0
>  24576 1995-09-25 03:39 ethernet
> > drwx--  2 mediamediau:object_r:unlabeled:s0
>  24576 1995-09-25 03:39 media
> > drwxrwxr-x  2 system   cacheu:object_r:unlabeled:s0
>  24576 2013-10-19 10:47 onehelp
> > drwxrwxr-x  2 root root u:object_r:unlabeled:s0
>  24576 1995-09-25 03:39 perfprofd
> > drwxrwx--x  3 root root u:object_r:unlabeled:s0
>  24576 2000-01-01 16:05 user
> > drwx--  2 root root u:object_r:unlabeled:s0
>  24576 1995-09-25 03:39 vold
> >
> >
> > On Thu, Mar 8, 2018 at 7:13 PM, kiran mardi <mardiki...@gmail.com
> <mailto:mardiki...@gmail.com>> wrote:
> >
> > Hi All,
> >
> > In one of our set we are seeing /data/misc/netd, keystore, user as
> unlabeled (dont know why it has become unlabeled). Since it is google AOSP
> module I am expecting restorecon should be part of AOSP code on these
> folder.
> >
> > ===
> > [Wed Mar 07 20:20:23.103 2018] [   19.018081] type=1400
> audit(946742413.155:43): avc: denied { unlink } for pid=1146 comm="netd"
> name="netd_pid" dev="mmcblk0p7" ino=406433 scontext=u:r:netd:s0
> tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
> >
> > [Wed Mar 07 20:20:23.103 2018] [   19.034844] type=1400
> audit(946742413.160:44): avc: denied { setattr } for pid=1161
> comm="installd" name="0" dev="mmcblk0p7" ino=407130
> scontext=u:r:installd:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
> permissive=0
> >
> > [Wed Mar 07 20:20:29.397 2018] [   25.229311] type=1400
> audit(946742419.495:47): avc: denied { write } for pid=1146 comm="netd"
> name="*rt_tables*" dev="mmcblk0p7" ino=406432 scontext=u:r:netd:s0
> tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
> >
> > [Wed Mar 07 20:20:29.425 2018] [   25.256023] type=1400
> audit(946742419.520:48): avc: denied { write } for pid=1146
> comm="Binder:1146_2" name="*netd_pid*" dev="mmcblk0p7" ino=406433
> scontext=u:r:*netd*:s0 tcontext=u:object_r:unlabeled:s0 tclass=file
> permissive=0
> > =
> > below folders are getting unlabeled.
> >
> > /data/misc/keystore
> > data/misc/netd
> > data/misc/user
> >
> > what may be the reason for this unlabeled?
> >
> > Is restorecon -R in init.rc file for these folder is the solution?
> want to know the real reason.
> >
> > Please help
> >
> > --
> > regards,
> > kiran mardi
> >
> >
> >
> >
> > --
> > regards,
> > kiran mardi
>
>


-- 
regards,
kiran mardi


Re: /data/misc contents are unlabeled

2018-03-08 Thread kiran mardi
some more data to the below issue. below are the folders which have become
unlabeled dont know the relation though.

drwxrwxr-x  2 dhcp dhcp u:object_r:unlabeled:s0
   24576 2013-03-30 16:44 dhcp
drwxrwx---  2 system   system   u:object_r:unlabeled:s0
   24576 1995-09-25 03:39 ethernet
drwx--  2 mediamediau:object_r:unlabeled:s0
   24576 1995-09-25 03:39 media
drwxrwxr-x  2 system   cacheu:object_r:unlabeled:s0
   24576 2013-10-19 10:47 onehelp
drwxrwxr-x  2 root root u:object_r:unlabeled:s0
   24576 1995-09-25 03:39 perfprofd
drwxrwx--x  3 root root u:object_r:unlabeled:s0
   24576 2000-01-01 16:05 user
drwx--  2 root root u:object_r:unlabeled:s0
   24576 1995-09-25 03:39 vold


On Thu, Mar 8, 2018 at 7:13 PM, kiran mardi <mardiki...@gmail.com> wrote:

> Hi All,
>
> In one of our set we are seeing /data/misc/netd, keystore, user as
> unlabeled (dont know why it has become unlabeled). Since it is google AOSP
> module I am expecting restorecon should be part of AOSP code on these
> folder.
>
> ===
> [Wed Mar 07 20:20:23.103 2018] [   19.018081] type=1400
> audit(946742413.155:43): avc: denied { unlink } for pid=1146 comm="netd"
> name="netd_pid" dev="mmcblk0p7" ino=406433 scontext=u:r:netd:s0
> tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
>
> [Wed Mar 07 20:20:23.103 2018] [   19.034844] type=1400
> audit(946742413.160:44): avc: denied { setattr } for pid=1161
> comm="installd" name="0" dev="mmcblk0p7" ino=407130
> scontext=u:r:installd:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
> permissive=0
>
> [Wed Mar 07 20:20:29.397 2018] [   25.229311] type=1400
> audit(946742419.495:47): avc: denied { write } for pid=1146 comm="netd"
> name="*rt_tables*" dev="mmcblk0p7" ino=406432 scontext=u:r:netd:s0
> tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
>
> [Wed Mar 07 20:20:29.425 2018] [   25.256023] type=1400
> audit(946742419.520:48): avc: denied { write } for pid=1146
> comm="Binder:1146_2" name="*netd_pid*" dev="mmcblk0p7" ino=406433
> scontext=u:r:*netd*:s0 tcontext=u:object_r:unlabeled:s0 tclass=file
> permissive=0
> =
> below folders are getting unlabeled.
>
> /data/misc/keystore
> data/misc/netd
> data/misc/user
>
> what may be the reason for this unlabeled?
>
> Is restorecon -R in init.rc file for these folder is the solution? want to
> know the real reason.
>
> Please help
>
> --
> regards,
> kiran mardi
>



-- 
regards,
kiran mardi


/data/misc contents are unlabeled

2018-03-08 Thread kiran mardi
Hi All,

In one of our set we are seeing /data/misc/netd, keystore, user as
unlabeled (dont know why it has become unlabeled). Since it is google AOSP
module I am expecting restorecon should be part of AOSP code on these
folder.

===
[Wed Mar 07 20:20:23.103 2018] [   19.018081] type=1400
audit(946742413.155:43): avc: denied { unlink } for pid=1146 comm="netd"
name="netd_pid" dev="mmcblk0p7" ino=406433 scontext=u:r:netd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0

[Wed Mar 07 20:20:23.103 2018] [   19.034844] type=1400
audit(946742413.160:44): avc: denied { setattr } for pid=1161
comm="installd" name="0" dev="mmcblk0p7" ino=407130
scontext=u:r:installd:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir
permissive=0

[Wed Mar 07 20:20:29.397 2018] [   25.229311] type=1400
audit(946742419.495:47): avc: denied { write } for pid=1146 comm="netd"
name="*rt_tables*" dev="mmcblk0p7" ino=406432 scontext=u:r:netd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0

[Wed Mar 07 20:20:29.425 2018] [   25.256023] type=1400
audit(946742419.520:48): avc: denied { write } for pid=1146
comm="Binder:1146_2" name="*netd_pid*" dev="mmcblk0p7" ino=406433
scontext=u:r:*netd*:s0 tcontext=u:object_r:unlabeled:s0 tclass=file
permissive=0
=
below folders are getting unlabeled.

/data/misc/keystore
data/misc/netd
data/misc/user

what may be the reason for this unlabeled?

Is restorecon -R in init.rc file for these folder is the solution? want to
know the real reason.

Please help

-- 
regards,
kiran mardi


Help: selinux training on android Platform

2017-12-06 Thread kiran mardi
Hi All,

May I know if there are any Selinux training conducted in Bangalore India
for android Platform?

I am interested in understanding the Architecture of selinux.

If any good material also be a help.

-- 
regards,
kiran mardi