[Sp!ke]

I'm trying to come up with a workable application policy that will allow users to install 3rd party apps but restrict what those apps can do by setting a top level application policy in the users software configuration.

Now I testesd this does actually work as intended but I am a little unclear about the meanings/consequences of some of the entries in the policy options.

Has anyone restricted 3rd party applications permissions in the same way that can shed light on this?

Perhaps a screenshot of the policy to see what you did and why?

[|||||||]

The allowed policy is a default policy, the dissallowed is one that has the disposition set to disallowed. you will need the cod/alx files for all 3rd party software you want to allow.

[Sp!ke]

You misunderstand me I think.

The top level policy also effects applications not listed in the software configuration... if you like a blanket policy effecting doanloads from the web too.

So I want to exploit this top level policy to restrict say... internal access of downloaded applications plus other restrictions too probably.

What I want is an understanding of what some of the other options actually do...

What does it mean by restrict or allow "local connections" for instance, what exactly does it consider local? Is there any documentation with an indepth explanation of all these policy options? The stuff I found is pretty light on detail.

[|||||||]

Livelink - Redirection

Check out Appendix B for descriptions. They are pretty self explanetory but I can clarify any if you want.

Internal is inside your firewall and External is the internet.

[Sp!ke]

Thanks for that, I'll have a look at it later when not mobile.

Has anyone else used this top level policy to restricy 3rd party downloaded applications? If so, what was the best balance of security/freedom.

Dissallow internal access is an obvious one as is the one about the 2 factor security thingy. I'm thinking the policy allowing access to messages should be disallow too (why would the application need that function?) The others I'm not entirely sure on.

Surely I'm not treading new ground, someone must have already been through this....

[|||||||]

If it is just a stupid game you should be able to disable most of the options there. There are 3rd party apps that access email and PIM which is why it is an option. another thing to note is the most common one i've seen is the event injector which is used for bluetooth keyboards, you may want to enable that.

[Sp!ke]

Interesting... Very interesting - I guess if the mailbox is set to win then the application can't change anything on the mailbox even if it has access to PIM info.

There is a bit of a concern that some kind of mass mailer exploit could be inadvertantly installed and used to access the mail/contacts and spam directly from the handset or steal data.

I'm going to have to look into this very thoroughly I think.

[|||||||]

Originally Posted by Sp!ke

Interesting... Very interesting - I guess if the mailbox is set to win then the application can't change anything on the mailbox even if it has access to PIM info.

There is a bit of a concern that some kind of mass mailer exploit could be inadvertantly installed and used to access the mail/contacts and spam directly from the handset or steal data.

I'm going to have to look into this very thoroughly I think.

I'm not sure what you mean by mailbox is set to win, if you are talking about on conflicts then no that's wrong.

But yes I would disable this access because any app that needs access to your PIM info or to the mail system on the handheld should probably be tested first.

[Sp!ke]

I also find it interesting that RIM don't seem to have any recommendations or best practices on the subject, afterall it should be a pretty hot topic.

When I rang t-support it went right over their heads - they didn't have a clue what I was trying to do. Nor did they understand the top level application policy hierachy... Not the level of support I pay good money for.