From MemberWiki

URL: http://www.openajax.org/member/wiki/Minutes-Special-DeviceAPIs-20080506

Attendees

• Larry Koved, IBM (Security TF)
• Suresh Chari, IBM (Security TF)
• Paddy Byers, Aplix (Mobile TF)
• Nikunj Mehta, Oracle (Mobile TF)
• Guillermo Caudevilla, Vodafone (Mobile TF)
• Caroline Belrose, Vodadone (Mobile TF)
• David Pollington, Vodafone (Mobile TF)
• Jon Ferraiolo, IBM (Security TF & Mobile TF)

Agenda

Feedback from Security TF on work so far within Mobile TF on a conceptual framework for mobile device API security

http://www.openajax.org/member/wiki/Mobile_Device_APIs_Security

Minutes

(Jon provides background on the phone call, how the industry decided that there needed to be a community effort around JavaScript APIs to mobile device services, and that dealing with security is considered critical.)

(Jon quickly summarizes use cases, with four deployment models, web, widgets, native apps loading a WebRuntime DLL, and a site specific browser.)

(Jon describes the thinking by the current thinking behind the security wiki page where we attempt to provide a conceptual framework and some guidelines for particular cases, but leave the final decisions to the vendors, and count on the market to drive the vendors towards good solutions.)

Caroline: Is there a risk that if we don't define quite a few guidelines, then the industry might drift towards insecure approaches?

Jon: Yes, there is a risk that vendors might adopt insecure approaches, and also an interoperability risk if vendors choose different approaches, which might confuse developers and users.

Nikunj: Our thinking is that besides a conceptual framework, we also provide recommendations.

Jon: Yes, but I'm not sure if I would say "recommendation" yet. We have to get further along to see how confident we are about what we are proposing. Maybe some things will be recommendations, and maybe others will be suggestions for consideration. But, yes, we want to identify the most common scenarios and the associated issues and make recommendations or suggestions for them.

Paddy: Aplix is creating a plugin that enables runtime APIs to Java. We have a permissions framework. Our aspiration for this work is sharing the permissions framework with other similar products. Imagine a JavaScript API to a certain function. There could be multiple underlying implementations of that API, not just ours. We want common APIs and a common security policy approach. The JavaScript says here are the things I require. We need a common approach for security policies that governs the use of those APIs.

Larry: I generally agree with that perspective. We don't want unexpected results on different platforms.

Jon: I am hearing that we want to have a common policy framework but OK if different products implement different security policies within that common framework.

Paddy: We use Java API permissions but another implementation might model after a different permission engine. Better to have a common way to express the APIs.

Jon: Makes sense to me.

Jon: Let's talk about one thing in particular. Paddy has proposed a feature string corresponding to each API, some sort of unique ID, and the ability to ask the system if you have permission to use that API.

Paddy: The permission check wouldn't happen at the user JavaScript level.

Larry: What is the programming model? What are the types of security ??? to enforce? What are the constraints on those functions? For example, getcurrentlocation(). Do we want to do something like Java where there is a call to a Java-like security manager? Versus the OpenAjax Hub which is more of a message passing paradigm.

Suresh: I think Paddy's right. You need a standard way of asking for the feature you want to access. Is that correct, Paddy?

Paddy: We have been talking about deployment models, both for installed widgets and web site. Have a security manager or access control. Uniformly intercepts all security-relevant actions. Making a decision based on the identities of the things making the action. URL for a web site or a widget identified via distinguished name. Then what action is attempted, and particular circumstances passed as parameters. The Security manager intercepts. Doesn't live in JavaScript land. Lives in the browser or a plugin, something that is protected.

Larry: OK, sounds very familiar. Java security works like this. Applet has a certain set of requirements. There also is JAAS to authenticate / authorize users. But you need other attributes for mobile workflows. In the regulated space, in Switzerland, for example, some transactions are OK in Switzerland but not outside of Switzerland. So the location attribute can be important.

Larry: Let me tell you my concerns from a pragmatic perspective. I've worked on Java security for 12 years. It functions correctly, but has a couple of deficiencies. Operationally, I have observed that people can't figure out how to write Java security policies. I've a tool for Java security, SWORD4J (http://alphaworks.ibm.com/tech/sword4j) for to help developers figure out Java security policies. What I have found is that people have trouble with Java's stack-based security policy. I like your apporach but the challenge will be to keep it simple enough while still enforcing what the developer's intent. My personal opinion is that we need something similar but simpler than Java that covers base requirements.

Paddy: Because of JavaScript, you can't make distinctions between call stacks if everything is in the same frame. So, we wouldn't have the full generality of JavaScript stack introspection. But we do want the notion of a trusted subsystem. I know this is possible in case of a Java bridge. The trusted subsystem is trusted to not expose the full set of APIs to its clients. We want to capture this in some sort of general way.

Larry: Does everyone here understand how Java security works?

Jon: I don't.

A sampling of Java 2 security reference materials:

Koved, et al., Understanding Java 2 Platform Security Permissions - A Practical Approach http://www.cs.umd.edu/class/spring2005/cmsc433/lectures/security-javaone.pdf

Pistoia, et al. Java 2 Network Security http://domino.research.ibm.com/comm/research_people.nsf/pages/pistoia.pubs.html/$FILE/PistoiaJavaSecBook.pdf

Li Gong, Inside Java 2 Platform Security http://books.google.com/books?id=XfWlYWVzo20C&dq=gong+%22inside+java+platform+security%22&pg=PP1&ots=18NQUJzPs-&sig=v7kZL6H3ikMBvnMx-04PUIbnLAs&hl=en&prev=http://www.google.com/search%3Fhl%3Den%26q%3DGong%2B%2522inside%2Bjava%2Bplatform%2Bsecurity%2522%26btnG%3DSearch&sa=X&oi=print&ct=title&cad=one-book-with-thumbnail#PPP1,M1 http://www.amazon.com/Inside-Java-Platform-Security-Implementation/dp/0201787911

Pistoia, et al., Enterprise Java Security http://www.pearsonhighered.com/educator/academic/product/0,,0321118898,00%2Ben-USS_01DBC.html http://books.google.com/books?hl=en&id=naa36Dc_ydEC&dq=%22marco+pistoia%22+pdf&printsec=frontcover&source=web&ots=JC2iRPVbbq&sig=KJHuG-yfjcuxmzMOv_EnWl5GXJ4

Larry: Java looks at all of the code in the runtime stack and checks the authorization of each caller in the stack. If any code is not authorized, then an exception is thrown. The problem is that developers can't figure out what's in the calling stack. To enable "privileged code", the authorization test is short circuited by a call to doPrivelege. There are books and reference materials on Java 2 security (see above). Question is whether we can adopt these basic concepts. Get desired properties but not as much complexity. Java is probably the closest thing that exist to what we need.

Paddy: Regarding the difficulties in writing policy, is it just something that is intrinsically difficult?

Larry: It is intrinsically difficult. We wrote a tool (SWORD4J; see reference above) to help developers figure out the security policies. Code analysis tools can't really be effective with JavaScript because of the extensive use of eval() to execute dynamically generated JavaScript. Need a simpler approach that leverages domains or signatures.

Larry: Coming to the end of the call. Next steps?

Jon: Larry needs to send links to info on Java security. (done. see above)

Jon: Next question is whether the security white paper or whatever should be driven by Mobile TF, with collaboration from Security TF, or the other way.

(Conclusion: drive from Mobile TF due to close coupling with API effort and expected higher participation level from Mobile TF)

Caroline: OMTP is doing something similar. Should we try to align the two efforts?

Jon: I would guess yes, but I don't know what OMTP is doing because they are trying to agree to allow information to be shared outside of OMTP. I am scheduled to talk to Nick Alcott on May 23.

Caroline: Yes, we (OMTP) are trying to get agreement to release some things to the public.

(Jon/Caroline agree to have a phone call next week Thursday or Friday to coordinate on OMTP)