[r-mr1] radio: Allow finding qti uce service

[ix5]

radio: Allow finding qti.uceservice

qcrild as part of the radio domain needs to find com.qualcomm.qti.uceservice::IUceService

Move public definitions back to vendor

There was no need to keep the definitions shared between system and vendor when the domains using them were contained in our vendor sepolicy only.

Revert shell dmesg

Original commit was typo'd, it meant to allow shell, not system_server to read syslog.
However, that'd be a neverallow:
system/sepolicy/domain.te:519:

neverallow appdomain kernel:system { syslog_read syslog_mod syslog_console };

system/sepolicy/private/shell.te:22:

.# XXX Transition into its own domain?
app_domain(shell)

[MarijnS95]

I have a hunch this should be:

hal_attribute_hwservice(hal_telephony, vnd_qti_uce_hwservice)

In hal_telephony.te.

[ix5]

@MarijnS95 might taking another look?

[MarijnS95]

@ix5 That's pretty crazy, shouldn't ims be a server domain to be allowed to add (host) IUCEService? Or was that wrong judgement by 346be22?

If it is, please:

Fixes: 346be22 ("ims: Label new services and grant add_hwservice access.")

But I don't see any other domain with the rights to find/host this service... Perhaps because I have never used this and anyone doing so (PE) is still in permissive.

• Who hosts this service?
• Do we at some point need a new hwservice "attribute" to shove ims-specific services under?

[MarijnS95]

akatsuki:/ # lshal | grep -i uce
X     Y android.hidl.base@1.0::IBase/com.qualcomm.qti.uceservice                                  0/1        770    518
DM    Y com.qualcomm.qti.uceservice@2.0::IUceService/com.qualcomm.qti.uceservice                  0/1        770    518
DM    Y com.qualcomm.qti.uceservice@2.1::IUceService/com.qualcomm.qti.uceservice                  0/1        770    518
akatsuki:/ # ps -A 770
USER           PID  PPID     VSZ    RSS WCHAN            ADDR S NAME
system         770     1   59588   4536 binder_io+          0 S imsrcsd

So imsrcsd hosts it, which is ims_exec, so ims. Should be a server domain, did you run-test this on-device?

[MarijnS95]

We should get @Paulbouchara to test this in parallel with us on PE since they use IMS and go enforcing soon™, in particular the remaining add_hwservices should probably be moved to hal_attribute_hwservice while falling under the hal_server_domain(ims, hal_telephony) catch-all.

Iirc hwbinder_use at the bottom of ims.te is granted by one of these macros as well?

[Paulbouchara]

We should get @Paulbouchara to test this in parallel with us on PE since they use IMS and go enforcing soon™, in particular the remaining add_hwservices should probably be moved to hal_attribute_hwservice while falling under the hal_server_domain(ims, hal_telephony) catch-all.

Iirc hwbinder_use at the bottom of ims.te is granted by one of these macros as well?

The next PE release will be on enforcing, as every releases that will follow, so sure, I'll test this asap when I'll be back and report with logs

[MarijnS95]

@ix5 One more thing: the denial shown in the logs tries to find (and perhaps add later) this service for the radio domain, but this PR allows hosting (adding) it from the ims domain...

ims adds/hosts it, radio (why it is added to hal_telephony here) finds/uses it?

[ix5]

@MarijnS95 ims was already hosting the service via the add_hwservice() macro.

That macro, however, forbids any other domains (even parent ones) from adding the service. So ims was not hosting this service in a server capacity, but just on its own.

The hal_attribute_hwservice() macro adds add_hwservice($1_server, $2), which would clash with add_hwservice(ims, vnd_qti_uce_hwservice).

The only way for a coredomain such as radio to access the IUceService is via hal_ server/client attribute empowerment.
As such, we need to keep the status quo (ims still hosts the service), just change the language.

-> Not true, we can still allow radio find find the service, just not add it (which is not needed anyway).

[MarijnS95]

Final verdict: radio only needs to find the service (and have binder communication with the domain hosting it, ims) so we're better off not adding it to hal_telephony since then:

• radio is a server domain, and would incorrectly be allowed to host it;
• ims would become a server domain, and is incorrectly allowed to host all other services in the list.

As posted in master...MarijnS95:ims-attribute-group we should check whether more hwservices in the hal_telephony domain are actually not hosted by radio at all, and are better separated so that radio can only read them.

(Note that qcrild runs under the radio domain)

[ix5]

For posterity, this was the original description of the "solution" using HAL attributes we discarded:

---

This accomplishes the following:

• Wrestle control over vnd_qti_uce_hwservice from ims domain
  (add_hwservice() macros includes a neverallow for other domains to add the service in any way)
• All clients of hal_telephony are now allowed to access com.qualcomm.qti.uceservice::IUceService
  This includes radio, which is a client domain of hal_telephony.

Since ims is no longer allowed access to vnd_qti_uce_hwservice, it needs to be converted into a server of hal_telephony via the hal_server_domain() macro.
N.b.: imsrcsd hosts the IUceService, so it really needs to be a server and not only a client.

Denial:

avc: denied  { find } for interface=com.qualcomm.qti.uceservice::IUceService \
    sid=u:object_r:radio:s0 scontext=u:object_r:radio:s0 \
    tcontext=u:object_r:vnd_qti_uce_hwservice:s0 tclass=hwservice_manager

---

Plus a small fixup