[SailfishDevel] Suggestion: expose androids intents on dbus

Mon Feb 23 19:37:53 UTC 2015

Hi Eli, Cathal

What i meant to convey is that i managed to execute commands such as am and
input, by crafting a script that helps with the environment.
This opens up some interesting possibilities in communicating with apps
inside the dalvik vm.

It seems Cathal is more adept than I am in these realms.
To clarify a bit, i was really only thinking about one-way communication,
to the Android apps from native ones.
For this purpose i imagine am will do fine, although better solutions are
always welcome.
Thus I'm not proposing, at least yet, that aliendalvik is written to
accomodate this, rather that an am-wrapper is made (by Jolla) with the
proper security mechanisms in place.

The intents that need to be published (is that the proper term?) in order
to handle basic functionality such as making calls and sending/composing
emails etc. are provided by aliendalvik dummy-apps that relay the call to
the Sailfish navive apps over dbus (exatly how, i don't know). This seems
like a sound way of doing communication from the VM(s), but for sending
things into Dalvik it is probably not needed to make it so complicated.

To answer your concerns Eli; only time will tell how important android
support will be, and i agree it is probably not good to construct very
intricate dependencies. However, this part i feel can provide a fair few
benefits in the meantime without too much work.

My immediate thoughts on what can be achieved with this, are cover actions
for android applications, widgets or companion apps and various automation
solutions.

Coderus has since made a small daemon-ish app that relays intents and input
it receives over dbus. Big thanks!
https://github.com/CODeRUS/aliendalvik-control

He also seemed interested in making a replacement navigation bar with
overlays like in ScreenTapShot, which sounds like a fun idea.

As for security implications, intents *may* be fine, but sending unchecked
arbitrary input to any android app surely isn't, at least without prior
approval from the user.

Btw, Cathal, Aliendalvik was just moved to a chroot in U11, adding a fair
bit of security on top of the, perhaps flawed, semi-sandbox that it already
is.

Regards,
Anton

2015-02-22 22:19 GMT+01:00 Cathal Garvey <cathalgarvey at cathalgarvey.me>:

> I may be mistaken, but:
>
> Android uses a global signalling system called "intents", where usually
> each publicly accessible mode of an app has a corresponding intent. You can
> launch an intent, which is (I think) globally visible, which tells an app
> to turn on, or to activate the camera, or to re-scan the SD card.
>
> Apps may also use Intents to signal things that they want a response to.
> Apps may use intents to say "any other apps out there have anything special
> they'd like to do with a github.com URL?", and other apps can say "Yea,
> I'm the github app and I can open it" or "Yea, I'm Firefox and I can open
> it".
>
> What am.sh does (I think, haven't looked past the name) is mimic the "am"
> command in Android, a terminal program that sends arbitrary Intents as
> directed by the user. Am is usually only used as a debugging tool and does
> not form the back-end of actual Android apps that use intents.
>
> What the poster was suggesting, which I think is a good idea if security
> can be ensured, is that Alien Dalvik should be written to expose Intents on
> DBus so that applications outside Alien can see and perhaps respond to
> what's happening inside Alien. I don't know much about DBus but I imagine
> it's already written to accomodate DBus message sandboxing or namespacing,
> so security wise I think the cards are likely to be in Sailfish's hands,
> not Alien's. Though, as Alien is closed source and likely doesn't run in a
> sandbox, it's not like security is really something worth worrying about;
> too late! :)
>
> On 22/02/15 21:12, E.S. Rosenberg wrote:
>
>> 2015-02-15 21:23 GMT+02:00 Anton Thomasson <antonthomasson at gmail.com
>> <mailto:antonthomasson at gmail.com>>:
>>
>>     Hi
>>
>>     I recently managed to execute Android commands from outside of Alien
>>     Dalvik.
>>     This was achieved by looking at how it's done when apps are launched
>>     and Alien Dalvik is started normally.
>>
>>     To see the resulting scripts, go here:
>>     https://github.com/attah/alien-tools
>>
>>     Now to the point, I think these should be exposed for use in
>>     sailfish native apps.
>>     The way I see it being done is by adding a daemon that forwards
>>     intents that it receives over dbus.
>>     This solves a couple of things, firstly that it seems to require
>>     root for the intents to take effect and secondly it enables us to
>>     add a layer of security so that the user is prompted when app wants
>>     to invoke an intent. This obviously needs a "allow permanently"
>>     option, otherwise intents won't be very useful. Using a daemon also
>>     takes care of the fact that it would have to execute in a rather
>>     particular environment. That is what i have managed to set up in
>>     alien-tools, but it is essentially the same as in
>>     /opt/alien/system/script/start_alien.sh, which is what is invoked by
>>     the aliendalvik.service. So spawning the daemon from there would work.
>>
>>     Polkit seems to be the way to do handle permissions, so that should
>>     work out. I also think that this whole thing is better done, at
>>     least in part, by Jolla. Especially since it needs to work with
>>     Alien Dalvik which is 3rd-party, and so that it goes together well
>>     with the workflow of the os in general. Thus this email. :)
>>
>>     I'm not sure how much else, apart from intents, that we'd like to
>>     have exposed. I found that the "input" application works as well,
>>     and many other should too. The scary part her is that i could send
>>     input without being root. Not sure that is a very good idea. And
>>     even if we would add som security layer, who is to check what is ok
>>     and what is not? Intents at least have a limited scope whereas input
>>     can do pretty much anything.
>>
>>     What do you guys think?
>>
>>     Regards,
>>     Anton (attah)
>>
>>     _______________________________________________
>>     SailfishOS.org Devel mailing list
>>     To unsubscribe, please send a mail to
>>     devel-unsubscribe at lists.sailfishos.org
>>     <mailto:devel-unsubscribe at lists.sailfishos.org>
>>
>> Hi attah,
>> I'm not familiar with android so forgive me if I'm completely
>> misunderstanding what is happening here.
>> I mainly have lots of questions and probably not so much extra input...
>>
>> Are you basically using alien as a 'shell' (just like one would use
>> tcsh, zsh etc) to execute jars? Isn't that how alien always works?
>>
>> What are these intents?
>>
>> My gut says that more access might be dangerous, also in the sense that
>> someone may end up writing a jolla native app that still depends on
>> alien being there and having a ton of unnecessary overhead (without even
>> talking about the security implications), surely not the aim of jolla or
>> the community if we want to improve the jolla ecosystem...
>>
>> (What are the security implications of what you are proposing?)
>>
>> Hope you don't mind my flood of questions, the subject matter looks
>> interesting to me and so far no one seems to have commented at all...
>>
>> Regards,
>> Eli
>>
>>
>> _______________________________________________
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to devel-unsubscribe at lists.
>> sailfishos.org
>>
>>
> --
> Scientific Director, IndieBio Irish Programme
>  Got a biology-inspired business idea that $50,000 -
>  & 3 months in a well equipped lab could accelerate?
>  Apply for the Summer programme in Ireland:
>  http://indie.bio/apply-to-ireland
> Twitter:  @onetruecathal
> Phone: +353876363185
> miniLock: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
> peerio.com: cathalgarvey
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe at lists.
> sailfishos.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20150223/dc31bc9d/attachment.html>