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
Post by Xiaofeng LeiHi Nick,
After set PRODUCT_FULL_TREBLE_OVERRIDE to false, the errors on new
1) Error on accessing nonplat_service_contexts_file from servicemanager
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
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
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
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
Post by 'Nick Kralevich' via Android Security DiscussionsMaybe your nonplat_service_contexts is being ignored because of this?
https://android.googlesource.com/platform/external/selinux/+/57fdb1f490d30275b8fd356568555f9ddc11b216%5E%21/
-- Nick
Post by Xiaofeng LeiThanks 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
Post by 'Nick Kralevich' via Android Security DiscussionsUnfortunately, 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
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
Post by Xiaofeng Lei127|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
Post by 'Nick Kralevich' via Android Security DiscussionsCan 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?
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
Post by Xiaofeng LeiHi Nick,
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
Post by 'Nick Kralevich' via Android Security DiscussionsCan you please send over the SELinux denial message after having
applied that patch? The message should have changed.
-- Nick
Post by Xiaofeng LeiHi 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
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
Post by 'Nick Kralevich' via Android Security DiscussionsPost by Xiaofeng LeiHi,
I'm trying to add the seLinux policies for a new native binder
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"
Post by Xiaofeng LeiAnd 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
type mcu_service_service, service_manager_type;
mcu.service u:object_r:mcu_service_service:s0
But in SELinux policy you are calling it "mcu.service"
Post by Xiaofeng Leitype 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
Visit this group at
https://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/d/optout.
--
--
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
Visit this group at
https://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/d/optout.
--
--
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
Visit this group at
https://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/d/optout.
--
--
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
Visit this group at
https://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/d/optout.
--
--
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
Visit this group at
https://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/d/optout.
--
--
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+***@googlegroups.com.
Visit this group at https://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/d/optout.