On Jan 11, 2015 8:28 AM, "Daniel Doron" <[email protected]> wrote: > > BTW, FYI, I did try using the binder as recommended. > I followed this example: http://www.androidenea.com/2010/03/share-memory-using-ashmem-and-binder-in.html#comment-form_903870610350693814 > > but I am hitting again a wall because : > > E/SELinux ( 172): avc: denied { add } for service=android.vendor.IEneaBuffer scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:default_android_service:s0 tclass=service_manager > E/ServiceManager( 172): add_service('android.vendor.IEneaBuffer',7) uid=1000 - PERMISSION DENIED > > apparently, according to domain.te policy: > > # Do not allow service_manager add for default_android_service. > # Instead domains should use a more specific type such as > # system_app_service rather than the generic type. > # New service_types are defined in service.te and new mappings > # from service name to service_type are defined in service_contexts. > neverallow domain default_android_service:service_manager add;
Sounds to me like u need to add a service context for your service in service_contexts > > > Daniel. > > On Sun, Jan 11, 2015 at 5:59 PM, Daniel Doron <[email protected]> wrote: >> >> Hi Stephen, >> >> I have some Binder questions. Can you point me to the relevant >> mailing list / forum / group ? >> >> Thanks, >> Daniel. >> >> On Thu, Jan 8, 2015 at 5:48 PM, Daniel Doron <[email protected]> wrote: >> > Thanks Stephen, I'll start digging. >> > >> > On Thu, Jan 8, 2015 at 5:16 PM, Stephen Smalley <[email protected]> wrote: >> >> (restored cc line for list; keep discussion on list please) >> >> >> >> Yes, of course you can use binder; surfaceflinger is already a binder >> >> service, and there are commands and services under frameworks/native >> >> that are using Binder IPC. Look under frameworks/native/cmds and >> >> frameworks/native/service. >> >> >> >> It is already allowed for surfaceflinger to create and pass back a Unix >> >> domain socket over binder to a client, and then have the client use that >> >> socket; that is an already existing pattern in Android. >> >> >> >> What is not currently allowed is for surfaceflinger to create Unix >> >> domain socket and have an app connect to that socket directly. We >> >> generally only do that for native daemons that don't use binder at all. >> >> If there is some genuine reason for doing that instead, you could >> >> perhaps allow it in your device-specific policy. But first I'd >> >> recommend trying to handle it in the standard Android way, i.e. using >> >> binder. And definitely do not use UDP. >> >> >> >> On 01/08/2015 09:53 AM, Daniel Doron wrote: >> >>> Hi Stephen, >> >>> >> >>> Could I use the binder directly inside the native framework? Any >> >>> examples available? >> >>> up to kitkat I could create a unix domain socket server inside >> >>> surfaceflinger (SOCKE_STREAM) and communicate with it from zygote or >> >>> bootanim context. With lollipop this does not work anymore. >> >>> >> >>> the udp was an attempt to get around this either via AF_INET or >> >>> AF_LOCAL. of course neither work ("permission denied"). >> >>> >> >>> Daniel. >> >>> >> >>> On Thu, Jan 8, 2015 at 4:24 PM, Stephen Smalley <[email protected]> wrote: >> >>>> On 01/08/2015 02:49 AM, Daniel Doron wrote: >> >>>>> Hi >> >>>>> >> >>>>> please excuse my newb question, I am still trying to make head and tails >> >>>>> of the new security restriction in Android 5.0.*. >> >>>>> >> >>>>> my goal in the end is communicating via IPC or UDP with surfaceflinger >> >>>>> from an App (untrusted_app or shell for testing). >> >>>>> IPC : I get and audit message restricting this >> >>>>> UDP : I get a denied { create } >> >>>>> >> >>>>> Is there anyway (permitted) that I can communicate with surfacefliger >> >>>>> without making changes to the .te file? >> >>>> >> >>>> Current policy allows binder IPC between any app domain (including >> >>>> shell) and surfaceflinger. Not sure what you mean by IPC above; if >> >>>> System V IPC, that has never been supported on Android. UDP would be >> >>>> more costly and less secure than using Binder. You can then pass open >> >>>> file descriptors across the binder IPC in order to perform direct file >> >>>> or socket I/O. That also is allowed by policy. You'd need to show your >> >>>> actual denials if you want more help on those. >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >> > > > > _______________________________________________ > Seandroid-list mailing list > [email protected] > To unsubscribe, send email to [email protected]. > To get help, send an email containing "help" to [email protected].
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
