Access denied by SELinux for system app, with rule

[gps...@gmail.com]

Hi,

I need my app to connect to my audio HAL through a unix socket created by my HAL..

I have my app running as system, as shown here (also signed with platform key):

root@hikey:/ # ps | grep xxx                                                                                                                                                                   
system    2619  1893  1561788 86956 SyS_epoll_ 0000000000 S com.xxx.xxx.xxx
root@hikey:/ # ps -Z | grep xxx                                                                                                                                                                
u:r:system_app:s0              system    2619  1893  1561788 86736 SyS_epoll_ 0000000000 S com.xxx.xxx.xxx
root@hikey:/ # 

I have this added to my device's SEpolicy rules:

auditallow system_app audioserver:unix_stream_socket { ioctl read getattr write setattr lock append bind connect getopt setopt shutdown connectto };

Rule with only connectto was suggested by audit2allow. I added other operations.

But I always get denied.

08-08 10:38:01.939 2622-2622/com.xxx.xxx.xxx W/ksetsdk.xxx: type=1400 audit(0.0:511): avc: denied { connectto } for path=0023xxx scontext=u:r:system_app:s0 tcontext=u:r:audioserver:s0 tclass=unix_stream_socket permissive=0




Can anyone guide me on what I missed? Is there any rule in AOSP SEPolicy that contradicts with this one?

How do I get it to work?

Thanks

-Gaurav

 

[Diogo Ferreira]

Your sepolicy rule should actually read

allow system_app audioserver:unix_stream_socket { ioctl read getattr write setattr lock append bind connect getopt setopt shutdown connectto };

auditallow marks an allow event as an audit log target, meaning that allows will be logged.

This will work but, as a piece of advice, you are increasing the surface area of access to your socket to all system apps which is undesirable.

Diogo

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platform+unsubscribe@googlegroups.com.
To post to this group, send email to android-platform@googlegroups.com.
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

[gps...@gmail.com]

Hi Diogo,

Thanks for the reply. I can limit the attack surface once my app gets permission, probably moiving my app to it's own domain.

I had used auditallow just to get a log of if/when permission gets granted. auditallow should also grant permission just like allow, but with one log, right?

I have used allow and auditallow both, and it doesn't seem to have any effect. I still get denials. Is tcontext correct?

Regards

-Gaurav

To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.

[gps...@gmail.com]

There must've been some sync issue in my building aosp and changing SEPolicy rules.

I did more exhaustive testing and found:

(1) When app is signed by platform key, and requests system uid in manifest, it runs as system_app and following rule works:

auditallow system_app audioserver:unix_stream_socket { connectto };

(2) When app is signed by platform key, but doesn't request system uid in manifest, it runs as platform_app but following rule doesn't work:

auditallow platform_app audioserver:unix_stream_socket { connectto };

(3) If App is not signed by platform key, it runs as priv_app, and following rule doesn't work:

auditallow priv_app audioserver:unix_stream_socket { connectto };

I must've mixed up what rule was built into AOSP when I tested it.

It is still a mystery to me why priv_app or platform_app woon't work, but system_app would with similar rule.

Thanks

-Gaurav

[Justin Gregory]

Hello Gaurav,

I'm facing the exact same issue.  Did you ever find an answer to this?  I've pulled the policy from /sepolicy and run sepolicy-check on it to be 100% sure that my rules are making it in, but they're still being denied.  My app is a platform_app.

-- Justin

[Justin Gregory]

I found the answer, after adding a bunch of kernel logging.  Seems I was being bit by mls constraints.  I put my app in its own domain and added "mlstrustedsubject", and that fixed it.

-- Justin

[Kiran mardi]

Hi All,

Tried with mlstrustedsubject for domain and it works fine for android P trebble architecture.