Re: /data/misc contents are unlabeled

[William Roberts]

On Tue, Mar 13, 2018 at 11:45 PM, kiran mardi  wrote:
> Hi Stephen,
>
> Please correct me if I am wrong.
> 1. restorecon_recurssive /data in system/core/rootdir/init.rc will not
> run/apply on every bootup?

No, as Stephen stated before, and I quote, "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"

This is for performance reasons, no need to run a costly recursive restorecon
if the file_contexts.bin file hasn't changed. But, if their was a bug
in this feature,
it possibly could cause it not to run.

> expectation is it should be running on every bootup(unlabeled issue
> should be solved).
>
> 2. Looks like the issue is reproduce when we upgrade from M to N. I see the
> change of restorecon_recurssive is already part of M as well.
>
> can this issue occur if the upgrade is partial or something?

I've only ever seen this when you're attempting to access something
before the trigger. This restorecon happens on the post-fs-data
trigger IIRC. Which (obviously) happens after the data partition is decrypted
and mounted.

Considering you saying it's not 100% reproducible,
are you racing the restorecon_recursive?

>
> On Fri, Mar 9, 2018 at 9:38 PM, kiran mardi  wrote:
>>
>> 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"  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?
>>>
>
>
>
> --
> regards,
> kiran mardi

Re: /data/misc contents are unlabeled

[kiran mardi]

Hi Stephen,

Please correct me if I am wrong.
1. restorecon_recurssive /data in system/core/rootdir/init.rc will not
run/apply on every bootup?
expectation is it should be running on every bootup(unlabeled issue
should be solved).

2. Looks like the issue is reproduce when we upgrade from M to N. I see the
change of restorecon_recurssive is already part of M as well.

can this issue occur if the upgrade is partial or something?

On Fri, Mar 9, 2018 at 9:38 PM, kiran mardi  wrote:

> 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"  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?
>>
>>


-- 
regards,
kiran mardi

Re: /data/misc contents are unlabeled

[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"  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: /data/misc contents are unlabeled

[Stephen Smalley]

On 03/09/2018 08:13 AM, Stephen Smalley 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?

Also, were there any interesting log messages on the first boot after the 
upgrade (i.e. when we would expect the restorecon_recursive to execute)?  Look 
for any logcat or dmesg messages with SELinux: or avc: prefixes.

Re: /data/misc contents are unlabeled

[Stephen Smalley]

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

[kiran mardi]

Hi Stephen,

Please find my replay below inline.

Regards,
Kiran Mardi

On Thu, Mar 8, 2018 at 10:57 PM, Stephen Smalley  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  > 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  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   >> 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
> > >

Re: Re: /data/misc contents are unlabeled

[Stephen Smalley]

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  > wrote:
> 
> Is this on AOSP master or a particular release branch?
> [Kiran]: it is particular release branch Android N.

Which one?

> 
>  
> 
> 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?
 
> 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 
> 
>  # We restorecon /data in case the userdata partition has been reset. 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.

> 
>  
> 
> 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 media        media        u:object_r:unlabeled:s0         
>       24576 1995-09-25 03:39 media
> > drwxrwxr-x  2 system       cache        u: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    >> 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
> >
> >
> >
> >
> > --
> > re

Re: /data/misc contents are unlabeled

[kiran mardi]

Hi Stephen,

Please find my response inline.

Regards,
Kiran Mardi

On Thu, Mar 8, 2018 at 8:56 PM, Stephen Smalley  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 

   # We restorecon /data in case the userdata partition has been
reset.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  > 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

[Stephen Smalley]

Is this on AOSP master or a particular release branch?

Is this occurring on a clean install or on an upgrade from a previous version?

There should be a recursive restorecon by init.rc of /data already from 
post-fs-data which should label everything.

Is there perhaps an invalid context in your file_contexts configuration for 
these directories?
Does it pass checkfc validation against your policy file?

What does a restorecon -nv /data/misc/dhcp report from an adb shell?

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 media        media        u:object_r:unlabeled:s0               
> 24576 1995-09-25 03:39 media
> drwxrwxr-x  2 system       cache        u: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  > 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

Re: /data/misc contents are unlabeled

[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  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