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;*
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].
