Access denied by SELinux for system app, with rule

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Access denied by SELinux for system app, with rule

gps.uei
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
 

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Access denied by SELinux for system app, with rule

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

On Tue, Aug 8, 2017 at 11:58 AM, <[hidden email]> wrote:
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
 

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Access denied by SELinux for system app, with rule

gps.uei

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




On Tuesday, 8 August 2017 20:32:10 UTC+5:30, Diogo Ferreira wrote:
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

On Tue, Aug 8, 2017 at 11:58 AM, <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="XnKsJcD_AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">gps...@...> wrote:
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
 

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="XnKsJcD_AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">android-platfo...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="XnKsJcD_AgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">android-...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/android-platform" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/android-platform&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/android-platform&#39;;return true;">https://groups.google.com/group/android-platform.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Access denied by SELinux for system app, with rule

gps.uei

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


On Wednesday, 9 August 2017 19:29:06 UTC+5:30, [hidden email] wrote:

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




On Tuesday, 8 August 2017 20:32:10 UTC+5:30, Diogo Ferreira wrote:
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

On Tue, Aug 8, 2017 at 11:58 AM, <[hidden email]> wrote:
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
 

--
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-platfo...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/android-platform" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/android-platform&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/android-platform&#39;;return true;">https://groups.google.com/group/android-platform.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Access denied by SELinux for system app, with rule

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


On Monday, August 14, 2017 at 11:49:43 AM UTC-5, [hidden email] wrote:

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


On Wednesday, 9 August 2017 19:29:06 UTC+5:30, [hidden email] wrote:

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




On Tuesday, 8 August 2017 20:32:10 UTC+5:30, Diogo Ferreira wrote:
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

On Tue, Aug 8, 2017 at 11:58 AM, <[hidden email]> wrote:
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
 

--
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-platfo...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/android-platform" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/android-platform&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/android-platform&#39;;return true;">https://groups.google.com/group/android-platform.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Access denied by SELinux for system app, with rule

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

On Monday, July 16, 2018 at 9:50:30 AM UTC-5, Justin Gregory wrote:
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


On Monday, August 14, 2017 at 11:49:43 AM UTC-5, [hidden email] wrote:

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


On Wednesday, 9 August 2017 19:29:06 UTC+5:30, [hidden email] wrote:

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




On Tuesday, 8 August 2017 20:32:10 UTC+5:30, Diogo Ferreira wrote:
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

On Tue, Aug 8, 2017 at 11:58 AM, <[hidden email]> wrote:
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
 

--
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-platfo...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/android-platform" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/android-platform&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/android-platform&#39;;return true;">https://groups.google.com/group/android-platform.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.