Double checked the code, the issue 2) is fixed. So only issue 3) is left.
On Tuesday, November 6, 2018 at 8:50:25 AM UTC-8, Xiaofeng Lei wrote:
>
> After a clean build, the issue 1) for accessing nonplat_service_contexts_file
> is not reproducible now. Sorry for the wrong alarm.
>
> I still can see the issue 2) & 3).
>
> Regarding 3), I would like to provide more details:
>
> 11-05 17:37:15.429 3253 3253 I future.auto.ipc: type=1400 audit(0.0:9):
> avc: denied { write } for name="vty0" dev="tmpfs" ino=15726
> scontext=u:r:ipc_app:s0:c512,c768 tcontext=u:object_r:uart_device:s0
> tclass=chr_file permissive=1
> 11-05 17:37:46.479 3253 3253 I future.auto.ipc: type=1400 audit(0.0:10):
> avc: denied { connectto } for path="/dev/socket/ipc_proxy"
> scontext=u:r:ipc_app:s0:c512,c768 tcontext=u:r:ipc_controller:s0
> tclass=unix_stream_socket permissive=1
>
> To fix above errors, below rules are added:
>
> allow ipc_app ipc_controller:unix_stream_socket connectto;
> allow ipc_app uart_device:chr_file write;
>
> And I got similar reports from other teams too on some other projects. In
> previous Android N, we never saw such failure, not sure if there is any new
> feature adding some more restriction?
>
> Thanks,
> Xiaofeng
>
>
> On Monday, November 5, 2018 at 4:41:46 PM UTC-8, Xiaofeng Lei wrote:
>>
>> Hi Nick,
>>
>> After set PRODUCT_FULL_TREBLE_OVERRIDE to false, the errors on new
>> services have gone away. But I got some new error messages as below:
>>
>> 1) Error on accessing nonplat_service_contexts_file from servicemanager
>>
>> 12-31 21:21:44.499 509 509 I servicemanager: type=1400 audit(0.0:3):
>> avc: denied { read } for name="nonplat_service_contexts" dev="dm-1" ino=638
>> scontext=u:r:servicemanager:s0
>> tcontext=u:object_r:nonplat_service_contexts_file:s0 tclass=file
>> permissive=1
>> 12-31 21:21:44.499 509 509 I servicemanager: type=1400 audit(0.0:4):
>> avc: denied { open } for
>> path="/vendor/etc/selinux/nonplat_service_contexts" dev="dm-1" ino=638
>> scontext=u:r:servicemanager:s0
>> tcontext=u:object_r:nonplat_service_contexts_file:s0 tclass=file
>> permissive=1
>> 12-31 21:21:44.499 509 509 I servicemanager: type=1400 audit(0.0:5):
>> avc: denied { getattr } for
>> path="/vendor/etc/selinux/nonplat_service_contexts" dev="dm-1" ino=638
>> scontext=u:r:servicemanager:s0
>> tcontext=u:object_r:nonplat_service_contexts_file:s0 tclass=file
>> permissive=1
>>
>> The rule to access this is already defined in AOSP code:
>>
>> not_full_treble(`allow servicemanager nonplat_service_contexts_file:file
>> r_file_perms;')
>>
>>
>> Even I tried to add this rule manually, it's still not working.
>>
>>
>> 2) servicemanager tries to access default_android_service
>>
>>
>> 11-05 16:00:12.701 509 509 E SELinux : avc: denied { add } for
>> service=global_gesture_service pid=612 uid=1000
>> scontext=u:r:system_server:s0 tcontext=u:object_r:default_android_service:s0
>> tclass=service_manager permissive=1
>>
>>
>> I checked the process 509, it's just servicemanager process.
>>
>> 3) Similar to above question 1), even I add some policies to fix some
>> violations, it still reports same errors. Do you have any suggestion on
>> this?
>>
>> Thanks,
>> Xiaofeng
>>
>>
>> On Monday, November 5, 2018 at 12:18:10 PM UTC-8, nnk wrote:
>>>
>>> Maybe your nonplat_service_contexts is being ignored because of this?
>>>
>>>
>>> https://android.googlesource.com/platform/external/selinux/+/57fdb1f490d30275b8fd356568555f9ddc11b216%5E%21/
>>>
>>> -- Nick
>>>
>>> On Mon, Nov 5, 2018 at 12:09 PM Xiaofeng Lei <xiaofe...@ff.com> wrote:
>>>
>>>> Thanks Nick.
>>>>
>>>> Just want to let you know, all of services new added by us using binder
>>>> and vndbinder have such issue whatever it's binder server or binder
>>>> client,
>>>> while the HAL services using hwbinder is working well. I don't know if
>>>> this
>>>> is a clue.
>>>>
>>>> And I searched web, and some one had same issue as this, they suggested
>>>> to add the policy files to system/sepolicy, and need to add corresponding
>>>> changes in the CIL files under system/sepolicy. Not tried this solution
>>>> yet
>>>> since it might break some CTS.
>>>>
>>>> Regards,
>>>> Xiaofeng
>>>>
>>>>
>>>> On Monday, November 5, 2018 at 12:02:19 PM UTC-8, nnk wrote:
>>>>>
>>>>> Unfortunately, I'm not sure what's wrong then. Servicemanager is
>>>>> translating your service name into an SELinux label and not finding a
>>>>> match. As a result, it's using the default SELinux label.
>>>>>
>>>>> Here's the code where servicemanager converts a servicename into an
>>>>> SELinux label:
>>>>>
>>>>>
>>>>> https://android.googlesource.com/platform/frameworks/native/+/d111162fc442e1a94699a55f91b7eb6efc4bed0a/cmds/servicemanager/service_manager.c#102
>>>>> (line 102, your line numbers may differ)
>>>>>
>>>>> This function walks through the various *service_manager* mapping
>>>>> files, using those config files to translate a name into an SELinux
>>>>> label.
>>>>> Because the code cannot find a matching name, it uses the wildcard entry
>>>>> defined in service_contexts.
>>>>>
>>>>> See line 200 of
>>>>> https://android.googlesource.com/platform/system/sepolicy/+/41ab29eeb3b3f680bc9f019034d7c6e31aab1455/private/service_contexts#200
>>>>>
>>>>> (your line numbers may differ).
>>>>>
>>>>> I would start debugging this by tracing through the selabel_lookup
>>>>> code and seeing why it's returning an incorrect value.
>>>>>
>>>>> -- Nick
>>>>>
>>>>>
>>>>> On Mon, Nov 5, 2018 at 11:37 AM Xiaofeng Lei <xiaofe...@ff.com> wrote:
>>>>>
>>>>>> Here is the result:
>>>>>>
>>>>>> 127|df91_hu_mpc:/ # PS D:\> adb shell
>>>>>> sdf91_hu_mpc:/ # su
>>>>>> df91_hu_mpc:/ # find / -xdev -name '*service_contexts*' -print |
>>>>>> xargs grep -E 'McuService|mcu.service'
>>>>>> df91_hu_mpc:/ # find /system -xdev -name '*service_contexts*' -print
>>>>>> | xargs grep -E 'McuService|mcu.service'
>>>>>> df91_hu_mpc:/ # find /vendor -xdev -name '*service_contexts*' -print
>>>>>> | xargs grep -E 'McuService|mcu.service'
>>>>>> */vendor/etc/selinux/nonplat_service_contexts:McuService
>>>>>> u:object_r:mcu_service_service:s0*
>>>>>> df91_hu_mpc:/ #
>>>>>>
>>>>>> Regards,
>>>>>> Xiaofeng
>>>>>>
>>>>>> On Monday, November 5, 2018 at 11:09:31 AM UTC-8, nnk wrote:
>>>>>>>
>>>>>>> Can you please verify that the relevant service_contexts files on
>>>>>>> your device are up to date, and do not contain a reference to the old
>>>>>>> name?
>>>>>>>
>>>>>>> The file has moved over time, so something like:
>>>>>>>
>>>>>>> adb shell
>>>>>>> su
>>>>>>> find / -xdev -name '*service_contexts*' -print | xargs grep -E
>>>>>>> 'McuService|mcu.service'
>>>>>>> find /system -xdev -name '*service_contexts*' -print | xargs grep -E
>>>>>>> 'McuService|mcu.service'
>>>>>>> find /vendor -xdev -name '*service_contexts*' -print | xargs grep -E
>>>>>>> 'McuService|mcu.service'
>>>>>>>
>>>>>>> There should only be references to McuService not mcu.service.
>>>>>>>
>>>>>>> -- Nick
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 5, 2018 at 10:58 AM Xiaofeng Lei <xiaofe...@ff.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Nick,
>>>>>>>>
>>>>>>>> Here are related logs:
>>>>>>>>
>>>>>>>> 10-23 18:39:42.573 1159 1159 I mcu_service: mcuservice start
>>>>>>>> ServiceManager: 0x7a40e3f0c0
>>>>>>>> 10-23 18:39:42.575 506 506 E SELinux : avc: denied { add }
>>>>>>>> for service=McuService pid=1159 uid=0 scontext=u:r:mcu_service:s0
>>>>>>>> tcontext=u:object_r:default_android_service:s0 tclass=service_manager
>>>>>>>> permissive=1
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Xiaofeng
>>>>>>>>
>>>>>>>> On Monday, November 5, 2018 at 10:56:09 AM UTC-8, nnk wrote:
>>>>>>>>>
>>>>>>>>> Can you please send over the SELinux denial message after having
>>>>>>>>> applied that patch? The message should have changed.
>>>>>>>>>
>>>>>>>>> -- Nick
>>>>>>>>>
>>>>>>>>> On Mon, Nov 5, 2018 at 10:52 AM Xiaofeng Lei <xiaofe...@ff.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Nick,
>>>>>>>>>>
>>>>>>>>>> Yes, the McuService is the service name we used in the code, and
>>>>>>>>>> in previous change, it's was defined as "McuService" too in
>>>>>>>>>> service_contexts file, still saw same issue. To confirm this, I just
>>>>>>>>>> did
>>>>>>>>>> the update to set it back to McuService, and made a build, the logs
>>>>>>>>>> are
>>>>>>>>>> same as before, here is the change:
>>>>>>>>>>
>>>>>>>>>> diff --git a/common/service_contexts b/common/service_contexts
>>>>>>>>>> index 066cea8..abe76d4 100644
>>>>>>>>>> --- a/common/service_contexts
>>>>>>>>>> +++ b/common/service_contexts
>>>>>>>>>> @@ -4,6 +4,6 @@
>>>>>>>>>> # Faradayfuture Confidential Restricted.
>>>>>>>>>> #
>>>>>>>>>>
>>>>>>>>>> -mcu.service u:object_r:mcu_service_service:s0
>>>>>>>>>> +McuService u:object_r:mcu_service_service:s0
>>>>>>>>>> DiagService
>>>>>>>>>> u:object_r:diagnositc_server_service:s0
>>>>>>>>>> DiagEngine u:object_r:diag_engine_service:s0
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Xiaofeng
>>>>>>>>>>
>>>>>>>>>> On Monday, November 5, 2018 at 10:36:23 AM UTC-8, nnk wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Nov 5, 2018 at 10:34 AM Xiaofeng Lei <xiaofe...@ff.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm trying to add the seLinux policies for a new native binder
>>>>>>>>>>>> service named mcu_service, but it keeps reporting the error
>>>>>>>>>>>> message:
>>>>>>>>>>>>
>>>>>>>>>>>> 10-24 04:14:45.285 513 513 E SELinux : avc: denied { add
>>>>>>>>>>>> } for service=McuService pid=1252 uid=0
>>>>>>>>>>>> scontext=u:r:mcu_service:s0
>>>>>>>>>>>> tcontext=u:object_r:default_android_service:s0
>>>>>>>>>>>> tclass=service_manager
>>>>>>>>>>>> permissive=1
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The string you are trying to register is "McuService"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And if the seLinux is set as enforced mode, it's getting worse
>>>>>>>>>>>> to lunch this service reporting like "add_service uid=1000 -
>>>>>>>>>>>> PERMISSION
>>>>>>>>>>>> DENIED".
>>>>>>>>>>>>
>>>>>>>>>>>> Here are the settings I added for the service (in the target
>>>>>>>>>>>> seLinux files device/xx/sepolicy):
>>>>>>>>>>>>
>>>>>>>>>>>> service.te:
>>>>>>>>>>>>
>>>>>>>>>>>> type mcu_service_service, service_manager_type;
>>>>>>>>>>>>
>>>>>>>>>>>> service_contexts:
>>>>>>>>>>>>
>>>>>>>>>>>> mcu.service u:object_r:mcu_service_service:s0
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But in SELinux policy you are calling it "mcu.service"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> mcu_service.te:
>>>>>>>>>>>>
>>>>>>>>>>>> type mcu_service, domain;
>>>>>>>>>>>> type mcu_service_exec, exec_type, vendor_file_type, file_type;
>>>>>>>>>>>> init_daemon_domain(mcu_service)
>>>>>>>>>>>> ......
>>>>>>>>>>>> binder_service(mcu_service)
>>>>>>>>>>>> add_service(mcu_service, mcu_service_service)
>>>>>>>>>>>> ......
>>>>>>>>>>>>
>>>>>>>>>>>> I tried to add the rule "allow mcu_service
>>>>>>>>>>>> default_android_service:service_manager add;", but it failed to
>>>>>>>>>>>> pass the
>>>>>>>>>>>> build because of the never_allow rules on default_android_service.
>>>>>>>>>>>>
>>>>>>>>>>>> Could anyone give me the hand on such issue?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Xiaofeng
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>>> Google Groups "Android Security Discussions" group.
>>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>>>>> it, send an email to
>>>>>>>>>>>> android-security-discuss+unsubscr...@googlegroups.com.
>>>>>>>>>>>> Visit this group at
>>>>>>>>>>>> https://groups.google.com/group/android-security-discuss.
>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Nick Kralevich | n...@google.com
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>> Google Groups "Android Security Discussions" group.
>>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>>> send an email to
>>>>>>>>>> android-security-discuss+unsubscr...@googlegroups.com.
>>>>>>>>>> Visit this group at
>>>>>>>>>> https://groups.google.com/group/android-security-discuss.
>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Nick Kralevich | n...@google.com
>>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "Android Security Discussions" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to
>>>>>>>> android-security-discuss+unsubscr...@googlegroups.com.
>>>>>>>> Visit this group at
>>>>>>>> https://groups.google.com/group/android-security-discuss.
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Nick Kralevich | n...@google.com
>>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Android Security Discussions" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to
>>>>>> android-security-discuss+unsubscr...@googlegroups.com.
>>>>>> Visit this group at
>>>>>> https://groups.google.com/group/android-security-discuss.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nick Kralevich | n...@google.com
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Android Security Discussions" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to android-security-discuss+unsubscr...@googlegroups.com.
>>>> Visit this group at
>>>> https://groups.google.com/group/android-security-discuss.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>> --
>>> Nick Kralevich | n...@google.com
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to android-security-discuss+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/d/optout.
