Could anyone know that java code use symbian server write in C++

I suspect it may be possible using JNI, but am not sure. I'd suggest you
cross-post this query in the 'discussion.symbian.cplusplus' and
'discussion.symbian.java' groups for a more enlightened answer.

Mark
Symbian Developer Network

Fox Jiang wrote:
> Hi all
> Could anyone know that java code use symbian server write in C++?

The traditional way has been to have the server listen on a local socket
and java code to connect to that socket. You can make up your own
protocol between them. There are plenty of examples on the net.

I would assume that you cannot export any functionality requiring
capabilities over such an interface, since there is no way your server
can check that the other end is allowed to use such functionality. Any
ideas from Symbian on this point would be appreciated.

JNI is not available on most Symbian devices, since it's not a part of
J2ME/MIDP. I think PersonalJava does (or at least may) have JNI, so S80
may support it.

>
> BR/FOX
>

Mika

Yes, pJava supports JNI, but its only on a few phones, having since been
replaced by midp2.
There is no JNI like interface on midp2, but as Mika notes, you can use
sockets - see FAQ-1198 Can I access native functionality from a MIDlet?

I'm not sure I understand Mika's statement regarding capabilities. Mika, can
you give me a use case?

Regards
H

"Fox Jiang" <[email protected]> wrote in message
news:[email protected]...
> Hi all
> Could anyone know that java code use symbian server write in C++?
>
> BR/FOX
>
>

Hamish Willee wrote:
> I'm not sure I understand Mika's statement regarding capabilities. Mika, can
> you give me a use case?

A typical use of a socket interface between native and Java has been to
get the current cellid. Cellid requires Location and ReadDeviceData, so
you should not give it out to anybody who doesn't have those
capabilities. You can't check capabilities over a socket connection, and
midlets can't have capabilities anyway. So in principal, an application
that gives out cellid over a socket shouldn't pass Symbian Signed.

This whole issue is one of the big questions with the trusted platform:
under what rules are our applications allowed to provide functionality
to non-native environments (Perl, Python, Java, flash, etc.)?

If the capabilities are user-grantable, then we could assume that the
native side could prompt the user when somebody connects over the
socket. It just would be very irritating, since we'd have to prompt each
time since you can't verify the identity of the program on the other
side of the socket to see it's the same one as previously (this was one
of the things I was arguing with Sander about earlier - the ability to
prove who you are over the network).

For non-user-grantable capabilities it would seem that you can never
allow that functionality to be used by non-native apps? The whole thing
is of course not self-consistent, since most apps that want, say cellid,
will communicate that to somebody outside the phone, which is of course
non-native too.

>
> Regards
> H

Mika

"Mika Raento" <[email protected]> wrote in message
news:%[email protected]...
> Hamish Willee wrote:[color=green]
>> I'm not sure I understand Mika's statement regarding capabilities. Mika,
>> can
>> you give me a use case?
>
> A typical use of a socket interface between native and Java has been to
> get the current cellid. Cellid requires Location and ReadDeviceData, so
> you should not give it out to anybody who doesn't have those capabilities.
> You can't check capabilities over a socket connection, and midlets can't
> have capabilities anyway. So in principal, an application that gives out
> cellid over a socket shouldn't pass Symbian Signed.[/color]

What about this: the server app and the midlet are packaged together in a
single sis file, probably with the server in it's own sis file. The sever
needs the capabilities to be allowed to install and without the server the
midlet will not work.

--
Sander van der Wal
www.mBrainSoftware.com

> This whole issue is one of the big questions with the trusted platform:
> under what rules are our applications allowed to provide functionality to
> non-native environments (Perl, Python, Java, flash, etc.)?
>
> If the capabilities are user-grantable, then we could assume that the
> native side could prompt the user when somebody connects over the socket.
> It just would be very irritating, since we'd have to prompt each time
> since you can't verify the identity of the program on the other side of
> the socket to see it's the same one as previously (this was one of the
> things I was arguing with Sander about earlier - the ability to prove who
> you are over the network).
>
> For non-user-grantable capabilities it would seem that you can never allow
> that functionality to be used by non-native apps? The whole thing is of
> course not self-consistent, since most apps that want, say cellid, will
> communicate that to somebody outside the phone, which is of course
> non-native too.
>[color=green]
>>
>> Regards
>> H
>
> Mika[/color]

Sander van der Wal wrote:
> What about this: the server app and the midlet are packaged together in a
> single sis file, probably with the server in it's own sis file. The sever
> needs the capabilities to be allowed to install and without the server the
> midlet will not work.
>
You still need to make sure that nobody else is connecting to your
server.

If the midlets have the 'import' directory like normal apps, the server
could create a key and put it in that directory.

Mika

"Mika Raento" <[email protected]> wrote in message
news:[email protected]...
> Sander van der Wal wrote:[color=green]
>> What about this: the server app and the midlet are packaged together in a
>> single sis file, probably with the server in it's own sis file. The sever
>> needs the capabilities to be allowed to install and without the server
>> the midlet will not work.
>>
> You still need to make sure that nobody else is connecting to your
> server.[/color]

True, but this is not different from linking to a library. The library
itself doesn't know who's linking to it.

> If the midlets have the 'import' directory like normal apps, the server
> could create a key and put it in that directory.

Wouldn't that mean that the server would need an extra capability just for
this storing files in other app's folders?

--
Sander van der Wal
www.mBrainSoftware.com

Sander van der Wal wrote:
> "Mika Raento" <[email protected]> wrote in message
> news:[email protected]...[color=green]
>> You still need to make sure that nobody else is connecting to your
>> server.
>
> True, but this is not different from linking to a library. The library
> itself doesn't know who's linking to it.[/color]

Yes it is: the library has capabilities and the loading process is
checked for those capabilities. That's the whole point: how do we
provide functionality to non-native apps?

>[color=green]
>> If the midlets have the 'import' directory like normal apps, the server
>> could create a key and put it in that directory.
>
> Wouldn't that mean that the server would need an extra capability just for
> this storing files in other app's folders?[/color]

Yes. But in your suggestion the server was bound to a single midlet
anyway - creating and checking a key isn't that big a hassle.

Mika

"Mika Raento" <[email protected]> wrote in message
news:[email protected]...
> Sander van der Wal wrote:[color=green]
>> "Mika Raento" <[email protected]> wrote in message
>> news:[email protected]...[color=darkred]
>>> You still need to make sure that nobody else is connecting to your
>>> server.
>>
>> True, but this is not different from linking to a library. The library
>> itself doesn't know who's linking to it.[/color]
>
> Yes it is: the library has capabilities and the loading process is checked
> for those capabilities. That's the whole point: how do we provide
> functionality to non-native apps?[/color]

Which means that you do not know who is calling you but you do know this
unknown caller is secure.

Anyway, as things stand now, non-native apps (meaning, executable formats
unknown to SWInstall) can only execute calls with unsigned or
user-assignable capabilities. Problem is, as soon as there is some extra
mechanism for capability checking, that extra mechanism must be as secure as
the current one. SWInstall is in the TCB.

Your idea of using keys, might work, but is it sufficient, i.e as trusted
ats SWInstall is? For instance, with keys you still have no guarantuee that
the client has not been tampered with, for instance.

Maybe it is better to lobby for having SWInstall support more languages.
Java is an obvious candidate. It will mean that apps written in these extra
languages must go through the same signing process as C++ apps.[color=green]
>>[color=darkred]
>>> If the midlets have the 'import' directory like normal apps, the server
>>> could create a key and put it in that directory.
>>
>> Wouldn't that mean that the server would need an extra capability just
>> for this storing files in other app's folders?[/color]
>
> Yes. But in your suggestion the server was bound to a single midlet
> anyway - creating and checking a key isn't that big a hassle.[/color]

The problem might well be that writing the server is not the problem,
getting it signed is. If the server needs all kinds of fancy capabilities,
but you cannot prove that it is secure enough, it will not be signed. It
doesn't matter much whether the communication mechanism is Symbian native
IPC or some special-purpose server using sockets.

--
Sander van der Wal
www.mBrainSoftware.com

Sander van der Wal wrote:
> Your idea of using keys, might work, but is it sufficient, i.e as trusted
> ats SWInstall is? For instance, with keys you still have no guarantuee that
> the client has not been tampered with, for instance.
>
> Maybe it is better to lobby for having SWInstall support more languages.
> Java is an obvious candidate. It will mean that apps written in these extra
> languages must go through the same signing process as C++ apps.
>
> The problem might well be that writing the server is not the problem,
> getting it signed is. If the server needs all kinds of fancy capabilities,
> but you cannot prove that it is secure enough, it will not be signed. It
> doesn't matter much whether the communication mechanism is Symbian native
> IPC or some special-purpose server using sockets.
>

Yes, we are back where I started the conversation: everybody will want
to continue providing extra functionality to Java midlets, Python, flash
etc. There are so far no guidelines from Symbian as to under what
conditions that might be allowed. I was asking for such guidelines.

There are a lot of testing houses. Having an open socket most likely
will not show up in the testing. I reckon there will be some software
doing this without disclosing it to the testing house - if and when
there's a problem there keys will be revoked.

But also as I said, for example people doing cell-based positioning will
most likely communicate that position to the outside world - it's of
limited use on the phone itself unless you can afford to bring all the
geodata you want to match it with to the phone. And the outside world is
not within the Symbian sandbox. So either they won't allow anybody
ReadDeviceData or they will allow it and it will escape the sandbox.

In the extreme: you could also publish the data to an outside web
service and then pull it back from that external service to Java. I
don't think cutting out that middleman _reduces_ security.

I don't know who made the decision that cell-id is ReadDeviceData, but
it sure doesn't make much sense. But the issue is wider: there's lots of
data that is interesting to applications (profile, charger status,
battery status etc.) that is protected under user-grantable capabilities
but should still of course not be handed to outside the sandbox.

Mika

"Mika Raento" <[email protected]> wrote in message
news:[email protected]...
> Sander van der Wal wrote:[color=green]
>> Your idea of using keys, might work, but is it sufficient, i.e as trusted
>> ats SWInstall is? For instance, with keys you still have no guarantuee
>> that the client has not been tampered with, for instance.
>>
>> Maybe it is better to lobby for having SWInstall support more languages.
>> Java is an obvious candidate. It will mean that apps written in these
>> extra languages must go through the same signing process as C++ apps.
>>
>> The problem might well be that writing the server is not the problem,
>> getting it signed is. If the server needs all kinds of fancy
>> capabilities, but you cannot prove that it is secure enough, it will not
>> be signed. It doesn't matter much whether the communication mechanism is
>> Symbian native IPC or some special-purpose server using sockets.
>>
>
> Yes, we are back where I started the conversation: everybody will want to
> continue providing extra functionality to Java midlets, Python, flash etc.
> There are so far no guidelines from Symbian as to under what conditions
> that might be allowed. I was asking for such guidelines.[/color]

Consider Symbian's position. You have this secure system, with all kinds of
procedures, code etc in place to keep it secure. It appears that there is
only one language (C++) that is enabled to take full advantage of the
protected features. There are some other languages that cannot use these
protected features, unless they resort back to something that some people
would name a trick, and the normal (paranaoid 😉 ) people will call a
loophole.

In such a situation Symbian can only close the loophole, by not letting
these tricky servers be signed. A political standpoint, and the only one
they can take if they want to be taken seriously.

The alternative would be that C++ programs should take the full load of
getting Symbian Signed, and other languages would not. I wouldn't want to be
the person defending that position.

> There are a lot of testing houses. Having an open socket most likely will
> not show up in the testing. I reckon there will be some software doing
> this without disclosing it to the testing house - if and when there's a
> problem there keys will be revoked.

The server would need a capability to read the data. It should not matter
whether the data gets out of the server or not. iF a server can read the
data, it can get out, and the signing process should be base on the
possibility, not the stated functionality.

> But also as I said, for example people doing cell-based positioning will
> most likely communicate that position to the outside world - it's of
> limited use on the phone itself unless you can afford to bring all the
> geodata you want to match it with to the phone. And the outside world is
> not within the Symbian sandbox. So either they won't allow anybody
> ReadDeviceData or they will allow it and it will escape the sandbox.

So, they can always implement their app in C++ and go through the Symbian
Signed process, just like everybody else.

> In the extreme: you could also publish the data to an outside web service
> and then pull it back from that external service to Java. I don't think
> cutting out that middleman _reduces_ security.

> I don't know who made the decision that cell-id is ReadDeviceData, but it
> sure doesn't make much sense. But the issue is wider: there's lots of data
> that is interesting to applications (profile, charger status, battery
> status etc.) that is protected under user-grantable capabilities but
> should still of course not be handed to outside the sandbox.

The problem is not that an app can post sensitive date, the problem is that
the attempt at getting at sensitive data should be impossible to do
silently.

--
Sander van der Wal
www.mBrainSoftware.com

Sander van der Wal schrieb:
[color=green]
>> Yes, we are back where I started the conversation: everybody will want to
>> continue providing extra functionality to Java midlets, Python, flash etc.
>> There are so far no guidelines from Symbian as to under what conditions
>> that might be allowed. I was asking for such guidelines.
> [...]
> In such a situation Symbian can only close the loophole, by not letting
> these tricky servers be signed. A political standpoint, and the only one
> they can take if they want to be taken seriously.[/color]

Are there actually any guidelines from Symbian for signing servers that
explicitly state the position you describe above?

In my view this question of "tricky servers" acting as proxies to APIs
with higher capabilities is significant beyond the realm of non-C++
languages...

I agree that this would be the "most secure" position to take, but at
the same itme I am doubtful that the black-box testing done in Symbian
Signed could really provide protection against servers implementing
interfaces that are "too generic" and allow such elevation of
privileges, even perhpas accidentally by providing services that are
slightly too flexible - especially without precluding several of the
more advanced uses of client/server code...

As an example, if I write a hypothetical server that is able to
enable/disable a FEP (CCoeEnv::InstallFepL, an interface requiring
WriteDeviceData caps), it could either expose this function as a simple
"on/off" service, with hard-coded FEP UIDs between which to toggle, thus
narrowing down the original API enough to make it worthless for anyone
else - or it could allow the client to pass the UID of any FEP. The
latter implementation would suddenly turn this into a backdoor to the
InstallFepL API. [*]

One way to prevent this would be requiring VID-lockdown of all Symbian
Signed servers - servers could be full of backdoors, but only a vendor's
own applications could use them. This principle could also be expanded
to signed Python/Java/whatever packages. However, this would effectively
rule out the possibility of writing servers that are accessed by
multiple processes through shared client DLLs or ECOM plugins.

ciao marcus

[*] Note: this is a contrived example, because in the case of a FEP, the
signing restrictions on the FEP itself are much stricter than those on
the InstallFepL call...

"Marcus Groeber" <[email protected]> wrote in message
news:[email protected]...
> Sander van der Wal schrieb:
>[color=green][color=darkred]
>>> Yes, we are back where I started the conversation: everybody will want
>>> to continue providing extra functionality to Java midlets, Python, flash
>>> etc. There are so far no guidelines from Symbian as to under what
>>> conditions that might be allowed. I was asking for such guidelines.
>> [...] In such a situation Symbian can only close the loophole, by not
>> letting these tricky servers be signed. A political standpoint, and the
>> only one they can take if they want to be taken seriously.[/color]
>
> Are there actually any guidelines from Symbian for signing servers that
> explicitly state the position you describe above?[/color]

There is chapter 5 in "Symbian OS platform security". It describes how a
server can check whether the client has certain capabilities, among other
check that can be made. A server connected to a client by sockets is not
able to make such checks. The chapter (or the book, AFAIK) doesn't say what
happens when a "socket-listening server" is presented for Signing.

> In my view this question of "tricky servers" acting as proxies to APIs
> with higher capabilities is significant beyond the realm of non-C++
> languages...
>
> I agree that this would be the "most secure" position to take, but at the
> same itme I am doubtful that the black-box testing done in Symbian Signed
> could really provide protection against servers implementing interfaces
> that are "too generic" and allow such elevation of privileges, even
> perhpas accidentally by providing services that are slightly too
> flexible - especially without precluding several of the more advanced uses
> of client/server code...

You should be able to see from the libraries linked and the capabilities
requested what a server can do. Any server that does a RSocket::Listen() and
needs the AlFfiles capability is capable of sending all files to anybody
connecting to that server, for instance.

> As an example, if I write a hypothetical server that is able to
> enable/disable a FEP (CCoeEnv::InstallFepL, an interface requiring
> WriteDeviceData caps), it could either expose this function as a simple
> "on/off" service, with hard-coded FEP UIDs between which to toggle, thus
> narrowing down the original API enough to make it worthless for anyone
> else - or it could allow the client to pass the UID of any FEP. The latter
> implementation would suddenly turn this into a backdoor to the InstallFepL
> API. [*]
>
> One way to prevent this would be requiring VID-lockdown of all Symbian
> Signed servers - servers could be full of backdoors, but only a vendor's
> own applications could use them. This principle could also be expanded to
> signed Python/Java/whatever packages. However, this would effectively rule
> out the possibility of writing servers that are accessed by multiple
> processes through shared client DLLs or ECOM plugins.
>
> ciao marcus
>
> [*] Note: this is a contrived example, because in the case of a FEP, the
> signing restrictions on the FEP itself are much stricter than those on the
> InstallFepL call...

I think it would be much better if non-C++ apps can connect to C++ servers,
using standard Symbian IPC mechanisms, and a mechanism to make non-C++ apps
installable with SwInstall. The platform is already fragmented enough as it
is, and it doesn't need more ways to do the same thing.

--
Sander van der Wal
www.mBrainSoftware.com