[SailfishDevel] Suggestion: expose androids intents on dbus

Cathal Garvey cathalgarvey at cathalgarvey.me
Sun Feb 22 21:19:28 UTC 2015


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


More information about the Devel mailing list